On Sat, 9 Aug 2008, Kostik Belousov wrote:
On Sat, Aug 09, 2008 at 11:27:58AM +0100, Robert Watson wrote:
On Sat, 9 Aug 2008, Peter Jeremy wrote:
On 2008-Aug-08 12:26:31 -0400, John Baldwin <[EMAIL PROTECTED]> wrote:
It should be setting D_TRACKCLOSE though so that close() reliably clears
the flag even in single-threaded processes. You can still get odd
behavior if you explicitly open it twice in an app and then close one of
the two fd's. You will no longer have IO permission even though you still
have one fd open. However, if you do that I think you deserve what you
asked for. :)
That behaviour may be legitimate: Your code links with libraries foo and
bar that each independently open /dev/io so they can frob different things
in IO space. libfoo needs ongoing access to device foo and so keeps its
descriptor open. libbar only needs once-off access to device bar and so
closes /dev/io once it's finished its initialisation. Libraries foo and
bar are completely independent and shouldn't need to know anything about
each other and your app shouldn't need to know that libraries it's using
frob around in IO space.
If that's the view, there should probably be a per-process counter,
although this is all a bit tricky anyway since file descriptors and
processes have a tenuous relationship.
Another interesting issue is the close on exec, esp. for /dev/io.
It seems that Linux recently grown full new API to handle FD_CLOEXEC races,
see http://udrepper.livejournal.com/20407.html
While /dev/io appeals to the UNIX "everything is a file" sensibility, I think
the system calls we have for this on i386 are more conceptually coherent.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
