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
pgpfYMBjsW3QR.pgp
Description: PGP signature
