cvs commit: src/sys/kern kern_exit.c
John Baldwin
jhb at freebsd.org
Wed Oct 25 15:04:13 UTC 2006
On Tuesday 24 October 2006 18:54, David Xu wrote:
> On Wednesday 25 October 2006 02:30, John Baldwin wrote:
> > On Monday 23 October 2006 18:47, David Xu wrote:
> > > On Monday 23 October 2006 23:33, John Baldwin wrote:
> > > > On Saturday 21 October 2006 19:59, David Xu wrote:
> > > > > davidxu 2006-10-21 23:59:15 UTC
> > > > >
> > > > > FreeBSD src repository
> > > > >
> > > > > Modified files:
> > > > > sys/kern kern_exit.c
> > > > > Log:
> > > > > Since revision 1.333 of kern_sig.c no longer uses P_WEXIT, the
> > > > > change opened a race window which can cause memory leak in signal
> > > > > queue. Here we free memory for signal queue when process state is
set
> > > > > to PRS_ZOMBIE.
> > > >
> > > > Is there any reason to not just harvest it in wait() instead?
> > >
> > > I prefer to free it earlier rather than delaying it if I can.
> >
> > But we already do the free'ing "later" (wait() really isnt' all that later
> > than exit1() for most processes) for sigacts, limits, etc. It would seem
> > that sigqueue and sigacts would have nearly identical lifetimes.
>
> But if system is under heavily memory loaded, doesn't freeing it earlier
make
> it better ? sigqueue does not have safe lifetime as sigacts, every thread
> has it, we check signal queue leak in thread_exit(), if you move the
> sigqueue_flush into wait1, then that code also has to be adjusted,
> because now not every thread will free the memory when it is exited,
> they no long have consistent behavior.
If it works as it is now, then it is fine. Forgot that sigqueue was
per-thread rather than per-process.
--
John Baldwin
More information about the cvs-src
mailing list