[Mono-devel-list] Re: [Mono-patches] r44192 - trunk/mcs/class/System/System.Net.Sockets

[Gonzalo Paniagua Javier]

On Mon, 2005-05-09 at 09:07 +0100, Dick Porter wrote:
> > +			accept_thread = Thread.CurrentThread;
> > +			try {
> > +				sock = Accept_internal(socket, out error);
> > +			} catch (ThreadAbortException the) {
> > +				if (disposed) {
> > +					Thread.ResetAbort ();
> > +					error = 10004;
> > +				}
> > +			} finally {
> > +				accept_thread = null;
> > +			}
> >  
> >  			if (error != 0) {
> >  				throw new SocketException (error);
> > @@ -1715,6 +1727,10 @@
> >  				IntPtr x = socket;
> >  				socket = (IntPtr) (-1);
> >  				Close_internal (x, out error);
> > +				if (accept_thread != null) {
> > +					accept_thread.Abort ();
> > +					accept_thread = null;
> > +				}
> >  
> 
> Isn't it possible for the accept_thread to be aborted while it is in the
> finally block?  Or Close()d multiple times while accept_thread != null?

After all the ghosts I've seen with regards to race condition, I won't
say 'no' to the first question, but 'very unlikely'

'if ((int) socket != -1) {' that's before getting in the if.

If someone is calling from multiple threads to this method we can say
"Any public static (Shared in Visual Basic) members of this type are
thread safe. Any instance members are not guaranteed to be thread
safe." :-)

> 
> Given how fragile thread aborting is, even without this race condition
> this might get ugly.  I can't think of a better solution offhand
> though...

Did you see the C test case in the bug report? There seems to be no
other way of closing from one thread if other is accepting than through
a signal that interrupts the call.

I don't really like this solution either...

-Gonzalo