Date: Mon, 7 Jul 2008 14:23:02 -0400 From: David Schultz <das@FreeBSD.ORG> To: Sergey Babkin <babkin@verizon.net> Cc: arch@FreeBSD.ORG, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: Re: Proposal: a revoke() system call Message-ID: <20080707182302.GA34751@zim.MIT.EDU> In-Reply-To: <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net> References: <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 07, 2008, Sergey Babkin wrote: > >>Rationale: > >> > >>In the multithreaded programs often multiple threads work with the > >>same file descriptor. A particularly typical situation is a reader > >>thread and a writer thread. The reader thread calls read(), gets > >>blocked until it gets more data, then processes the data and > >>continues the loop. Another example of a "reader thread" would be > >>the main thread of a daemon that accepts the incoming connections > >>and starts new per-connection threads. > > > >Have you tried to implement the functionality you're asking for ? > > > >You'll have to hunt down into all sorts of protocols, drivers > >and other code to find the threads sleeping on your fd so you can > >wake them. > > My thinking has been that if close() wakes them up, then things would be > inherited from there. The thing I didn't know is that apparently in many cases close() > doesn't wake them up. In Solaris, if you close a file descriptor that has blocked readers, the readers wake up and read() returns 0 bytes (EOF). (At least this is true if you close the local end of a pipe.) It seems like implementing the same behavior in FreeBSD would address your problem without introducing a new system call. Is there a good reason why this might not be the right thing to do?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080707182302.GA34751>