Re: close(2) while accept(2) is blocked

2013-04-06 Thread John-Mark Gurney
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

Re: close(2) while accept(2) is blocked

2013-04-05 Thread Jilles Tjoelker
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

Re: close(2) while accept(2) is blocked

2013-04-04 Thread Andriy Gapon
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

Re: close(2) while accept(2) is blocked

2013-04-04 Thread 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 2Thread 3 > ent

Re: close(2) while accept(2) is blocked

2013-04-01 Thread John Baldwin
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

Re: close(2) while accept(2) is blocked

2013-03-30 Thread Bakul Shah
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 >

Re: close(2) while accept(2) is blocked

2013-03-30 Thread Mark
> 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

Re: close(2) while accept(2) is blocked

2013-03-30 Thread John-Mark Gurney
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

Re: close(2) while accept(2) is blocked

2013-03-29 Thread Bakul Shah
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

Re: close(2) while accept(2) is blocked

2013-03-29 Thread Carl Shapiro
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

Re: close(2) while accept(2) is blocked

2013-03-28 Thread Jilles Tjoelker
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