Date: Wed, 16 Apr 2003 12:30:15 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <Pine.GSO.4.10.10304161219510.14483-100000@pcnet1.pcnet.com> In-Reply-To: <00f501c303dc$969bfec0$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > To: "David Xu" <davidxu@freebsd.org> > Cc: <freebsd-threads@freebsd.org>; ""Craig Rodrigues"" <rodrigc@attbi.com> > Sent: Wednesday, April 16, 2003 10:58 AM > Subject: Re: libpthread patch > > > I thought it might also be the UTS trying to interrupt > > the thread (kse_thr_interruot) while it was in the kernel > > (assuming the UTS did get the signal). > > Can you try a patch for kern_exit.c ? > http://people.freebsd.org/~davidxu/kern_exit.c.diff No, it didn't work. Same thing. The application is calling waitpid() with WNOHANG and pid -1. I am pretty sure there is a child process because I added some debugging statements and could see that it was spawned, saw it with top(1), and also saw when the waitpid() was called. Everything looks good on this end. The next call to waitpid(-1) returns the missed process id. I am not sure why WNOHANG is causing waitpid to return 0 for libkse and -1 for libc_r. It seems as if the process is still running so waitpid with WNOHANG _should_ return 0. I am not sure why ACE expects it to return the process id if it is still active. The test seems to do the right thing with libc_r, so that's kind of confusing. See if you can figure it out. The test is Process_Manager_Test. I'll continue to debug it also, and clean up my patches in general. I'd like to commit soon so we can get other testers going. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304161219510.14483-100000>