Bakul Shah wrote this message on Sat, Mar 30, 2013 at 13:22 -0700:
On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney j...@funkthat.com wrote:
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
On Thu, Apr 04, 2013 at 08:43:17PM +0300, Andriy Gapon wrote:
on 01/04/2013 18:22 John Baldwin said the following:
I think you need to split the 'struct file' reference count into two
different counts similar to the how we have vref/vrele vs
vhold/vdrop for vnodes. The fget for accept and
on 01/04/2013 18:22 John Baldwin said the following:
I think you need to split the 'struct file' reference count into two different
counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The
fget for accept and probably most other system calls should probably be
equivalent
On Thursday, March 28, 2013 12:54:31 pm Andriy Gapon wrote:
So, this started as a simple question, but the answer was quite unexpected to
me.
Let's say we have an opened and listen-ed socket and let's assume that we know
that one thread is blocked in accept(2) and another thread is
Bakul Shah wrote this message on Fri, Mar 29, 2013 at 16:54 -0700:
On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro carl.shap...@gmail.com wrote:
In other operating systems, such as Solaris and MacOS X, closing the
descriptor causes blocked system calls to return with an error.
What
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 2Thread 3
enters routine to read
enters routine to close
calls close(3)
On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney j...@funkthat.com wrote:
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 2Thread 3
On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon a...@freebsd.org wrote:
But the summary seems to be is that currently it is not possible to break
a thread
out of accept(2) (at least without resorting to signals).
This is a known problem for Java. Closing a socket that another thread is
block
On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro carl.shap...@gmail.com wrote:
In other operating systems, such as Solaris and MacOS X, closing the
descriptor causes blocked system calls to return with an error.
What happens if you select() on a socket and another thread
closes this socket?
So, this started as a simple question, but the answer was quite unexpected to
me.
Let's say we have an opened and listen-ed socket and let's assume that we know
that one thread is blocked in accept(2) and another thread is calling close(2).
What is going to happen?
Turns out that practically
On Thu, Mar 28, 2013 at 06:54:31PM +0200, Andriy Gapon wrote:
So, this started as a simple question, but the answer was quite
unexpected to me.
Let's say we have an opened and listen-ed socket and let's assume that
we know that one thread is blocked in accept(2) and another thread is
11 matches
Mail list logo
