Re: [Boost-users] Boost.Thread memory leak reported

From: Elisha Berns (e.berns_at_[hidden])
Date: 2005-08-29 14:05:54

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
a
> > 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
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users