Following on from Widcomm Thread restrictions on Win32 and Widcomm BluetoothListener stops getting connections, I first tried putting all calls to the Widcomm CRfCommPort API onto a new thread; that fulfilled that first part of the Widcomm statement: “An additional implication of this guideline is that derived functions must not call back into the stack with another SDK API.”

However it did not fix the problem where the WidcommBluetoothListener stopped accepting connections after a while.  So it seems like the second part of the statement really does mean we must use only one thread: “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 now I’ve implemented a scheme where we create a thread and force all API calls to be done from that thread only.  (In class WidcommPortSingleThreader we have the commands (PortWriteCommand, OpenServerCommand, etc) which we add to a queue, and then wait for the single thread to take that off the queue and action it).

Some more testing is required, but this seems to have fixed this problem.  I was able to create one thousand connections one after the other without problem.  That’s much more that it could manage previously, so it looks good.

Hopefully this also fixes the problem where send operations were getting stuck on Win32  (Widcomm faults in OBEX operations) — one of the operations now done on the single thread is CRfCommPort.Write.  When I get a moment I’ll test that too.