Date: Wed, 25 Feb 2004 09:46:25 +0900 From: Hye-Shik Chang <perky@i18n.org> To: Daniel Eischen <eischen@vigrid.com> Cc: python@freebsd.org Subject: Re: Need the help on debug the Python VS libpthread.. Message-ID: <20040225004625.GA20828@i18n.org> In-Reply-To: <Pine.GSO.4.10.10402241722080.3438-100000@pcnet5.pcnet.com> References: <opr3v3z30q8ckrg5@smtp.central.cox.net> <Pine.GSO.4.10.10402241722080.3438-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 24, 2004 at 05:26:13PM -0500, Daniel Eischen wrote: > On Tue, 24 Feb 2004, Jeremy Messenger wrote: > > > A workaround (not real fix?) as perky has committed[1]. There's something > > wrong with waitpid if it runs as libpthread, since without the workaround > > can run fine with libc_r. > > It is not necessarily a problem with libpthread. waitpid() can > return EINTR when interrupted by a signal. If SIGCHLD isn't > masked by the thread, then it is certainly plausible that it > can get interrupted by it. > > You may not have seen it with libc_r because it handles signals > differently as well as wrap waitpid() so it doesn't block the > process. Libpthread doesn't wrap waitpid() except to make it > a cancellation point. If its returning EINTR, I would suspect > that it has received a signal. I see. Thanks for the kind explanation and sorry for my confusing. :) The fix is checked in Python CVS. http://mail.python.org/pipermail/python-checkins/2004-February/039939.html Thanks, Hye-Shik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040225004625.GA20828>