close(2) while accept(2) is blocked

[Andriy Gapon]

on 30/03/2013 18:14 John-Mark Gurney said the following:
> As someone else pointed out in this thread, if a userland program
> depends upon this behavior, it has a race condition in it...
> 
> Thread 1		Thread 2		Thread 3
> 						enters routine to read
> enters routine to close
> calls close(3)
> 			open() returns 3
> 						does read(3) for orignal fd
> 
> How can the original threaded program ensure that thread 2 doesn't
> create a new fd in between?  So even if you use a lock, this won't
> help, because as far as I know, there is no enter read and unlock
> mutex call yet...
> 
> I decided long ago that this is only solvable by proper use of locking
> and ensuring that if you call close (the syscall), that you do not have
> any other thread that may use the fd.  It's the close routine's (not
> syscall) function to make sure it locks out other threads and all other
> are out of the code path that will use the fd before it calls close..
> 
> If someone could describe how this new eject a person from read could
> be done in a race safe way, then I'd say go ahead w/ it...  Otherwise
> we're just moving the race around, and letting people think that they
> have solved the problem when they haven't...
> 
> I think I remeber another thread about this from a year or two ago,
> but I couldn't find it...  If someone finds it, posting a link would
> be nice..
> 

I wish to abstract as much as possible from how an application may use, misuse or
even abuse the close+xxxx interaction.  But I think that the behavior that
provides more information / capabilities is preferable over the behavior that does
not.  E.g. your example above does not apply to a utility that has only two
threads.  The "three threads" problem can also be solved if all the threads
cooperate.  But as I've said.

-- 
Andriy Gapon