Following on from Widcomm single thread access, I’ve now moved all operations onto the ‘special thread’ and not just the connection-oriented ones.  So now StartInquiry, and StartDiscovery for instance are run on the main thread.  There’s still some tidying-up to do at some time.

This has been followed by a big round of testing.  I repeated my testing from Widcomm faults in OBEX operations where Win32 stopped sending after many megabytes.  I wasn’t able to reproduce this, so it seemed to have been fixed.  However I then tried repeating the test on the 2.4 version and couldn’t reproduce it either…  Until I switched user (XP’s fast-user switching) and then the data transfer stopped!  So it seems that there’s actually no problem with “buffer-empty” events stopping due to not being thread affinite, but instead that Widcomm keeps state in the current logon session and thus breaks if the session changes.  Yikes!  So be aware of this.  I wonder what happens when calling the API from a NTService…

Also the change doesn’t seem to have had any effect on the conflict with the Microsoft stack.  Oh well…

Advertisements