PaulStoffregen
Well-known member
Is configuring your temp folder on a normal drive an option?
{Windows rant mode} The problems I just fixed in teensy-monitor.exe turned out to be WIN32 ReadFile & WriteFile don't work together when called from separate threads when configured in the simpler blocking mode, which is the way you would naturally want to use them on separate threads. Normally you'd only want "overlapped" async I/O without threads, where blocking on anything stalls everything else. Seems as if Microsoft implemented the blocking API with a mutex, making it useless for multiple threads. Turns out you must use the more complicated "overlapped" async API if you want WriteFile running in 1 thread to be able to actually transmit while ReadFile is waiting in another thread for data to arrive (and when it returns with data, the waiting WriteFile finally gets to transmit - which is the reason Kurt's test program works 5 seconds later after Teensy transmit anything). So many things in Windows are like this, where Microsoft gives you a supposedly generic API like CreateFile, ReadFile, WriteFile, but then when you actually use it lots of things don't work except in some specific mode. While you must use overlapped on serial and HID with threads where you just want each thread to block, turns out you can't use async I/O at all on stdin & stdout. The teensy-serialmon.exe program for Arduino 1.8.x creates 2 extra threads just to work around the lack of async I/O for stdin & stdout, but then does everything using overlapped async I/O from a single thread.
I guess it's not as bad as the MacOS kernel panic triggered by certain usages of their async I/O API, which was the main motivation to move away from a single thread model.
Virtual drives having incomplete or inconsistent filesystem API support just so sees on-brand for Windows. {yeah, I'm still frustrated by ReadFile blocking WriteFile on another thread, even though it's now "fixed" by using overlapped mode}
{Windows rant mode} The problems I just fixed in teensy-monitor.exe turned out to be WIN32 ReadFile & WriteFile don't work together when called from separate threads when configured in the simpler blocking mode, which is the way you would naturally want to use them on separate threads. Normally you'd only want "overlapped" async I/O without threads, where blocking on anything stalls everything else. Seems as if Microsoft implemented the blocking API with a mutex, making it useless for multiple threads. Turns out you must use the more complicated "overlapped" async API if you want WriteFile running in 1 thread to be able to actually transmit while ReadFile is waiting in another thread for data to arrive (and when it returns with data, the waiting WriteFile finally gets to transmit - which is the reason Kurt's test program works 5 seconds later after Teensy transmit anything). So many things in Windows are like this, where Microsoft gives you a supposedly generic API like CreateFile, ReadFile, WriteFile, but then when you actually use it lots of things don't work except in some specific mode. While you must use overlapped on serial and HID with threads where you just want each thread to block, turns out you can't use async I/O at all on stdin & stdout. The teensy-serialmon.exe program for Arduino 1.8.x creates 2 extra threads just to work around the lack of async I/O for stdin & stdout, but then does everything using overlapped async I/O from a single thread.
I guess it's not as bad as the MacOS kernel panic triggered by certain usages of their async I/O API, which was the main motivation to move away from a single thread model.
Virtual drives having incomplete or inconsistent filesystem API support just so sees on-brand for Windows. {yeah, I'm still frustrated by ReadFile blocking WriteFile on another thread, even though it's now "fixed" by using overlapped mode}
