4
votes

According to MSDN for the DataReceived event, it says

The DataReceived event is raised on a secondary thread when data is received from the SerialPort object.

Does this mean there is just one secondary thread that always fires the event? Or does the SerialPort object create a new thread each time it fires the DataReceived event? So could my DataReceived event fire while I'm in the DataReceived event?

I tried to google this but couldn't find a good answer.

1
Same event every time. You register the event once using '+='. If you close the connection then each time it is opened you would need to register and then would be different every time. - jdweng
I get that it's the same event every time, but the event is being called from a thread from the SerialPort object. If that thread is different every time then it would be possible to call that event from another thread while you were in that event doing something else. However, if it were being called from the same thread then it wouldn't be possible. - Baddack
An invent is an interrupt which automatically switches processes and can be be called from anywhere in the app. - jdweng
You can check it by actually operating it. Thread ID should be acquired by this API. Thread.ManagedThreadId Property - kunif

1 Answers

1
votes

According to this post on the MSDN forums here.

When it does, data received in your case, it dips in the ThreadPool and calls QueueUserWorkItem() which allocates a thread pool thread to call your DataReceived event handler. It then immediately calls WaitCommEvent() again to wait for the next "something interesting".

It sounds like the SerialPort object uses a ThreadPool so although the DataReceived event is being called on different Threads, they already exist in the ThreadPool and therefor there is no overhead for creating new ones.

So it is possible to have the event fire even while you are in there because it will be on a different Thread.