I have created a Windows service that has two listening sockets that
appear to be working like they should. Once data comes in from sockets,
they do as little work as possible before they make a call to the
ThreadPool to keep the "system thread" work to a minimum.
Here are my two question regarding the "callback" events when data
actually comes in. Is there a single thread assigned from the frameworks
that does the callback work for the sockets or will each socket have its
own thread basically? When these threads are running the method
associated with read callback event, is that thread guaranteed to run to
completion before being interrupted (meaning do I need to worry about
making those methods re-entrance safe)?

Tim

Hi Tim

I assume by you mentioning callbacks that you are using BeginReceive/
EndReceive? If so then the callbacks are called on threadpool threads,
but the callback won't be called again until you issue another
BeginReceive call.

Or have I misunderstood and you are using Socket.Receive and then
using a threadpool thread to process the data read from the sync
socket call? If that is the case, then yes you could end up with more
than one thread pool thread running the callback code, assuming all
you are doing is looping round reading bytes from the socket and
passing them off to a threadpool worker to process in your callback
and then immediately reading more bytes.

Matt

On Aug 20, 7:05*am, Tim Barber <timfbar...@yahoo.com> wrote:
> I have created a Windows service that has two listening sockets that
> appear to be working like they should. Once data comes in from sockets,
> they do as little work as possible before they make a call to the
> ThreadPool to keep the "system thread" work to a minimum.
> Here are my two question regarding the "callback" events when data
> actually comes in. Is there a single thread assigned from the frameworks
> that does the callback work for the sockets or will each socket have its
> own thread basically? When these threads are running the method
> associated with read callback event, is that thread guaranteed to run to
> completion before being interrupted (meaning do I need to worry about
> making those methods re-entrance safe)?
>
> Tim

Hi Matt,

My apologizes for not being clearer. Your first assumption is the
approach that I took because that seems to be the most prevalent
approach taken by the MSDN examples. Thanks for the info because it
looks like my code is safe because I am dispatching a message to a
delegate before I call BeginReceive().

Tim

> Hi Tim
>
> I assume by you mentioning callbacks that you are using BeginReceive/
> EndReceive? If so then the callbacks are called on threadpool threads,
> but the callback won't be called again until you issue another
> BeginReceive call.
>
> Or have I misunderstood and you are using Socket.Receive and then
> using a threadpool thread to process the data read from the sync
> socket call? If that is the case, then yes you could end up with more
> than one thread pool thread running the callback code, assuming all
> you are doing is looping round reading bytes from the socket and
> passing them off to a threadpool worker to process in your callback
> and then immediately reading more bytes.
>
> Matt
>
> On Aug 20, 7:05 am, Tim Barber <timfbar...@yahoo.com> wrote:
>> I have created a Windows service that has two listening sockets that
>> appear to be working like they should. Once data comes in from sockets,
>> they do as little work as possible before they make a call to the
>> ThreadPool to keep the "system thread" work to a minimum.
>> Here are my two question regarding the "callback" events when data
>> actually comes in. Is there a single thread assigned from the frameworks
>> that does the callback work for the sockets or will each socket have its
>> own thread basically? When these threads are running the method
>> associated with read callback event, is that thread guaranteed to run to
>> completion before being interrupted (meaning do I need to worry about
>> making those methods re-entrance safe)?
>>
>> Tim
>