Date: Fri, 29 Sep 2000 07:19:54 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Roman Shterenzon <roman@harmonic.co.il> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: pthreads bug? Message-ID: <Pine.SUN.3.91.1000929065950.4817A-100000@pcnet1.pcnet.com> In-Reply-To: <970215688.39d451088fbef@webmail.harmonic.co.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Sep 2000, Roman Shterenzon wrote: > Hello, > I noticed some strange behavior in pthreads applications, > close on socket which is in accept() will be blocked untill there's a connection > to port and accept returns. Correct. FreeBSD pthreads locks file descriptors while they're in use. Since the thread in accept() has the file descriptor locked, performing a close() on that same file descriptor in another thread will block until the accept completes. The same thing would happen if you were doing a read() on the socket with no data ready instead of the accept(). To fix your program (or openldap), ensure the signal gets directed to the thread in accept() and handle the EINTR, or have a signal handling thread that does sigwait() for SIGHUP (or whatever) and then kill the thread in accept() with pthread_kill(). You could also use pthread_cancel() if there is cleanup handling that the thread needs to do before exiting. FWIW, I'm not sure that our pthreads library should prevent programs from shooting themselves in the foot by locking file descriptors. I'm of the mind that people kill people, not guns ;-) But removing the automatic locking of file descriptors needs to be looked at closely to ensure that it doesn't cause problems for the threads library itself. I think POSIX also mandates locking for stdio fds. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000929065950.4817A-100000>