Widcomm/Broadcom produces different SDKs for their different platforms, but the PDF documentation files in the the various SDKs looks very similar, so I printed the Windows CE/WM version and worked from that. Recently however I was reading from the Win32 version and found this statement:
“An additional implication of this guideline is that derived functions must not call back into the stack with another SDK API. Any SDK API that must be called as a result of a callback from the stack must be executed from the application main thread, not the callback execution context.”
So in a Widcomm-callback handler we shouldn’t call back into the stack. 😦 In the current code we do that — for instance when we have get pending data to send, and that stack sends us a ‘finished sending’ event, we call Write from there. Maybe its this that causes the “gets stuck sending” problem…
Anyway I’ve got some work in process to enable this, being tracked by bug 25410.
I intend just to
- Mark threads with a flag noting whether they’re from a Widcomm callback or not.
- Any time I make a call back into the stack, check that flag, and if set force the call onto another thread, e.g. via a Delegate.BeginInvoke/EndInvoke pair.
Other much more complex mechanisms are available, e.g. one I tried earlier was to action all Widcomm-callbacks on a new thread, but that was very slow.
Note however that the documentation says “from the application main thread”. As a library, we can’t know the application’s main thread. We could though create a single thread and pass all calls to the Widcomm API via it, but is that really required?? It would make things much more complex…