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 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 1Thr
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 accep
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
> equivalen
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 2Thread 3
> ent
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 c
On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney 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
>
> 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 clo
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 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 selec
On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro 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? Ideally select() should
On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon 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 is suppose
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
> ca
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 no
12 matches
Mail list logo
