Proposal: a revoke() system call

David Schultz das at FreeBSD.ORG
Mon Jul 7 18:52:34 UTC 2008


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?


More information about the freebsd-arch mailing list