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>