On Sun, Aug 25, 2002 at 11:44:36AM -0700, John M McIntosh wrote:
> 
> there still is the possibility from say a DLL running on a different 
> thread to lose a signal, a collision at write time for example. 
> Correcting this requires an OS level mutex lock, which might not be 
> possible in all platforms. Tho I guess we could code up some entry 
> points and null them out as the default, and or use a thread safe 
> mutex queue, again an OS issue.
> 
> Now if you want to suggest a change here and have an example of a 
> failure situation I'm all ears. Mmm also only 500 outstanding 
> interrupts at any time.

I'll report back on this one. I can definitely generate failures, but
I'm afraid that my edit/compile/test cycle now includes a few extra
steps for unplug_computer/reboot/disk_check/reopen_a_bunch_of_windows ;)

Anyhow, what I'm trying to do is read from a Win32 pipe without blocking
the Squeak VM, and I'm currently doing it with a Win32 thread that does a
one character read-ahead, and signals Squeak when a character is available
to be slurped into the image. It seems to work with one pipe, but when
I test it with lots of pipes reading and writing at once, I'm able to
generate all kinds of horrible failures. One of the failure symptoms is
lost signals, but I'm certainly not at the point where I understand
the root cause.

I'll let you know when I get something more definitive.

Dave

p.s. Alternative design suggestions for a non-blocking Win32 pipe would
be welcome. As near as I can figure, threads are how this sort of thing
is done on Windows, but maybe I'm missing something.