Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Apr 2013 20:06:13 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        freebsd-net@FreeBSD.org, FreeBSD Hackers <freebsd-hackers@FreeBSD.org>
Subject:   Re: close(2) while accept(2) is blocked
Message-ID:  <515DB305.70908@FreeBSD.org>
In-Reply-To: <20130330161434.GG76354@funkthat.com>
References:  <515475C7.6010404@FreeBSD.org> <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?515DB305.70908>