Date: Mon, 07 Jul 2008 12:49:17 -0500 (CDT) From: Sergey Babkin <babkin@verizon.net> To: Robert Watson <rwatson@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@FreeBSD.org, Sergey Babkin <babkin@verizon.net> Subject: Re: Re: Proposal: a revoke() system call Message-ID: <9820978.224231215452958017.JavaMail.root@vms227.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
>From: Poul-Henning Kamp <phk@phk.freebsd.dk> >In message <20080707162733.V63144@fledge.watson.org>, Robert Watson writes: > >>>> achieve something of the same end by opening /dev/null and then dup2()'ing >>>> to the file descriptor you want to revoke, perhaps? Right now there's a >>>> known >>> >>> That's a great idea. I haven't thought about it. It should do everything. >> >>Right, and possibly this means that no additional kernel support is required >>-- we just make it a libc or libutil interface. > >I can't see how that could possibly work... > >If you do a dup2(), the original fd is closed, and that still does not >release all threads that may be sleeing on it in device drivers. Device drivers definitely would be a pain. I guess it depends on the semantics of the driver close() routine in cdevsw. Even if it's called every time a process does close() - well, assuming that a process didn't share it through fork(), and if it did then the last process'es close() - then the driver might still not be handling correctly the wake-up of all the threads coming from this file descriptor. But I guess it's again connected to whether they can handle close() from a multithreaded application, with other threads still trying to read. Maybe make a new entry in devsw, requesting the driver to wake up all the sleepers (either coming from a particular file descriptor, or all the sleepers at all) and return EINTR for them. Then if we replace the entry in the file table first, the interrupted threads would handle the signal as usual, come back and find that when they try to restart the call on this descriptor, they get a hard error. Hm, maybe even a new devsw entry is not needed. Just pretend delivering a signal to all the threads, skipping the ones that aren't currently sleeping on a file I/O (i.e. running on sleeping on a synchronization primitive). Then just don't call any signal handler for this pretend-signal, return a EINTR and let it be handled in an usual way. -SB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9820978.224231215452958017.JavaMail.root>