Date: Fri, 29 Sep 2000 11:17:12 +0200 (IST) From: Roman Shterenzon <roman@harmonic.co.il> To: David Schwartz <davids@webmaster.com> Cc: freebsd-stable@freebsd.org, Alfred Perlstein <bright@wintelcom.net> Subject: RE: pthreads bug? Message-ID: <970219032.39d45e1810ccd@webmail.harmonic.co.il> In-Reply-To: <NCBBLIEPOCNJOAEKBEAKCEHHLAAA.davids@webmaster.com> References: <NCBBLIEPOCNJOAEKBEAKCEHHLAAA.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting David Schwartz <davids@webmaster.com>: > > > 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. > > It's observed on 4.0 - 4.1-STABLE, perhaps 4.1.1-STABLE as well, > > but I didn't > > try it. I don't have 3.5.1-STABLE system to test it there. > > It affects, for example, openldap - start it , then kill -15 it. > > It won't die (and it should). Now, try to telnet localhost 389 ; > > now it died. > > The same behavior is a program we're writing right now, it's very > > annoying, in > > fact we don't know how to deal with it. It works on solaris and linux. > > To do this deliberately is atrocious programming. In a multithreaded > program, file descriptors are shared resources much like memory. To have > one > thread close a file descriptor while you know another thread is using it > is > like calling free() on a memory block that you know another thread is > accessing. > > It is fraught with race conditions. For example, what happens if > another > thread calls 'open' 'dup' or 'socket' and recreates the file descriptor > you > just closed before the thread that is blocked in 'accept' can get the > CPU > back? (And please don't answer this by analyzing an implementation of > pthreads. Phtreads is a standard, any particular implementation of > pthreads > is not.) > > Why would any sane person do such a thing? And knowing that you have > this > in your own program, why wouldn't you just fix it? > > I grant that FreeBSD's handling of this situation could be better. But > to > deliberately and knowingly invoke this and expect a predictable response > is > crazy. (Unless you can point to chapter and verse in the pthreads > standard.) > > DS > You're partially right. First of all, some other, not only mine application use it, for example, like I said, openldap. And "It works on other OS(tm)". I don't have the standards document and I cannot check what should be the correct behavior. Then, this bug is not limited to accept. I almost sure the same behavior was observed when, thread1 had an open connection, and thread2 tried to close() it. This is quite common AFAIK. Just because it's shared resource, it should be possible to modify it from multiple threads, this is the definition of shared. Then, I think there's some other bug dealing with signal delivery, because I don't see main thread break out of accept with EINTR. This _is_ weird. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] 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?970219032.39d45e1810ccd>