Peter, I don't pretend to understand the design of Boost.Thread, so I can't and won't argue this point in terms of *correct design*, it would be presumptuous of me, to say the least. That said, I can comment on your two points below. For one, not all OSes are reliable. Windows 98 is unreliable as far as releasing/freeing resources from processes that are shut down. It has a poor tolerance for any kind of kernel handles that aren't shut down by the process itself. My firsthand experience with this issue dates back about two and a half years ago when I was hired as a consultant to figure out/fix problems with a Windows application that would intermittently hang or lock up the machine. Even forcibly shutting down the offending process did not fix the problem(s). The company couldn't diagnose the problem because they developed it on Windows 2000 and only a handful of customers ran it on Windows 98. When they initially reported the problem they failed to report that they were running it on Windows 98! Windows 2000 never displayed the offensive behavior, so they were at a loss to explain to their customers what was going on. And indeed Windows 2000 has a much, much higher tolerance for cleaning up leaky resources in a process. Although that application leaked both handles to GDI objects and memory, the point for me is simply that Windows 98 is an unreliable OS. Now, Microsoft OSes have gotten much more stable and reliable over the years, but if you don't have to rely on the OS, which may be flaky, why rely on the OS? Presumably you will respond that nobody in their right mind would write software for Windows 98 at this point and this is such a marginal 'edge case' that it really is of no concern. Well, unfortunately, there are still hundreds of millions of Windows 98 machines out there, and a lot of current, cutting edge software is STILL being written to run on those machines. Purportedly Microsoft tried to kill support for Windows 98 about 2 years ago until they realized how big the problem really is (is not was). Secondly, how many microseconds does it actually take to free the memory allocated by the threadmon mutex? Even if we are talking milliseconds here, which isn't likely, some application, somewhere would have to kill a few hundred if not a few thousand processes in order to notice an actual performance hit when shutting down. How many apps need to do such a thing? And what's more, if the OS needs to clean up some unfreed memory won't it take more or less the same number of microseconds as the application itself to clean it up? So that point doesn't seem to weigh in real strongly here. Well, I'm sure you get my drift... But your point about how it will only complicate the design of the library sounds like the most reasonable one here. But surely there must some relatively simple way to do this? Is there a way to have it deleted by a mechanism called at file scope when its object code is being unloaded? Anyways, I think boost needs to assume less about how reliable OSes are, and not at all if Boost.Thread runs on Windows 98 also. Elisha
Elisha Berns wrote:
Well, since I started this whole thing, I have to ask... If it's a singleton, doesn't it need to clean itself up? If the assumption is that the OS will clean it up when the process is killed, isn't that
bit shaky as far as sound assumptions go?
It's a perfectly sound assumption for today's OSes, even if you rely on them to clean up kernel resources (such as a Win32 HANDLE) and not just memory. Manually releasing everything with program lifetime duration just makes the process exit more slowly (but it keeps simple leak detectors happy).
In addition, there is no good place to put the delete. You have to
a play
games with atexit and then deal with the possibily of resurrection (singleton access after it's been deleted.)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users