In 2.5 on Win32 we made all calls into the Widcomm API come from one thread, this was due to the note in the Widcomm documentation as discussed at   However since then two people noted in the forums that on Windows Mobile some operations failed when called from an async callback.  One noted that in a DiscoverDevices callback that calling BeginDiscoverDevices failed, and another noted that a Connect failed when called from there.

So what do we learn from this?  If a library doesn’t state its threading requirements then assume the worst.  This is unlike the managed code I’ve created where everything is safe when called from multiple threads and from a callback.  I ensure that all invariants are correct and am holding no locks etc when I raise the callback etc.  So nothing is forbidden, and no special main thread is required.

So, since then in the Widcomm support code on both platforms we’ve made all user callbacks occur on a thread-pool thread.  Hopefully that’ll solve all the threading issues once and for all.  On the downside it could make a small change in behaviour, for instance the callbacks could take a slightly longer period to start after an event, and if there were multiple reads or writes released by a stack event then they could now run in parallel.