socket beginreceive and thread exit

7 Dec 2006 5:36 PM

William Stacey [C# MVP]

The doco for socket.BeginReceive says:

"All I/O initiated by a given thread is canceled when that thread exits. A
pending asynchronous operation can fail if the thread exits before the
operation completes."

I have been bitten by this recently. But it raises another question. If
you post another async read in a callback (as many do) from a prior read,
that 2nd BeginReceive is called on the IOCP thread, which can go away and
above should apply. So how does this ever work? Or is something fixed up
behind the covers. tia

--
William Stacey [C# MVP]

7 Dec 2006 5:44 PM

Henning Krause [MVP - Exchange]

Hello William,

I had the same issue quite some time ago. I believe the IOCP threads are
kept alive for this. Or there is some magic behind the scenes - anyway, it
works...

Best regards,
Henning Krause

Show quote

"William Stacey [C# MVP]" <william.sta***@gmail.com> wrote in message
news:OEygNZiGHHA.4904@TK2MSFTNGP04.phx.gbl...
> The doco for socket.BeginReceive says:
>
> "All I/O initiated by a given thread is canceled when that thread exits. A
> pending asynchronous operation can fail if the thread exits before the
> operation completes."
>
> I have been bitten by this recently. But it raises another question. If
> you post another async read in a callback (as many do) from a prior read,
> that 2nd BeginReceive is called on the IOCP thread, which can go away and
> above should apply. So how does this ever work? Or is something fixed up
> behind the covers. tia
>
> --
> William Stacey [C# MVP]
>
>
>

8 Dec 2006 5:48 AM

William Stacey [C# MVP]

Thanks Henning. I agree it works (at least for testing). But is this just
an latent app bug waiting to happen that you normally don't see in testing
and light use. For example, if we do another read in the callback on iocp
thread #3, maybe that thread stays around for awhile because the TP keeps
using it and maybe it does not based on its min/max algo. But what happens
if that thread gets collected by the TP and the receive is still
outstanding? Does socket check to see if thread is a TP thread and change
the thread owner of the socket to a thread that always lives? Are many
server apps out there having sporadic failures that never get resolved and
they chalked it up to some network glitch?

So how to trick *first read into being on an IOCP thread? I did a hack with
just a TP thread using QueueUserWorkItem and it seems to work, but I wonder
if it is just a bug waiting to happen as above. TIA

--
William Stacey [C# MVP]

Show quote