Date: Fri, 29 Sep 2000 22:00:04 +0200 (IST) From: Roman Shterenzon <roman@harmonic.co.il> To: Alfred Perlstein <bright@wintelcom.net> Cc: Daniel Eischen <eischen@vigrid.com>, freebsd-stable@FreeBSD.ORG Subject: Re: pthreads bug? Message-ID: <970257604.39d4f4c41cfff@webmail.harmonic.co.il> In-Reply-To: <20000929103756.I27736@fw.wintelcom.net> References: <20000929013521.C27736@fw.wintelcom.net> <Pine.SUN.3.91.1000929072626.7930A-100000@pcnet1.pcnet.com> <20000929103756.I27736@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Alfred Perlstein <bright@wintelcom.net>: > * Daniel Eischen <eischen@vigrid.com> [000929 04:29] wrote: > > > > I don't think it should be fixed unless we decide to remove the > > automatic locking of file descriptors. But if you do come up > > with a clean solution, please run it by me. I have some massive > > changes to the threads library that are currently under review. > > Well the hackish idea that I had was to set the thread runnable > but somehow set a flag so that it knows it's the "accept() being > broken by close() wakeup." The accept()ing thread can then unlock > the file and return EBADF or whatever it's supposed to. After what Daniel said, I'm not sure about the close()/accept() behavior, however I know how Solaris7 and Linux 2.2.x behave. But, there should be escape from read(), i.e. close() must be permitted on socket on which there's a read(). Perhaps the original LINGER (via setsockopt) behavior should be retained when the current behavior is needed. I'd be glad to test any provided patches. --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?970257604.39d4f4c41cfff>