On Sat, Apr 13, 2002 at 08:51:48AM -0700, Ned Konz wrote:
> On Saturday 13 April 2002 07:37 am, David T. Lewis wrote:
> 
> > Yes, I would like to see this done, but I'm not sure about using
> > timeouts to implement it.
> 
> I wasn't suggesting using timeouts to implement it. I just thought 
> that providing access to the native OS serial character/minimum read 
> API (on Unix, VMIN, VTIME in termios; there are corresponding 
> controls in Windows) could give better fine-tuning.

Ah, right. That sounds good.

> > The generalized aio support which Lex added to the Unix VM provides
> > the necessary underpinnings for Unix platforms. I not sure how it
> > would be done for Windows, Mac and RiscOS, but I'm sure that a
> > reading of the tcl source will provide the necessary clues.
> 
> Perhaps the aio support would work on those platforms. It just uses 
> select(); isn't this pretty generally available? Ruby, for instance, 
> works on at least Unix and windows and never blocks the entire 
> process on file I/O. I remember that Windows' select() is specific to 
> sockets, but there is a wait for event there.

I'm not sure how it's done on non-unix platforms. Chances are that tcl,
Ruby, Perl and such have all figured it out. Hmmm, must be on one of
these CDROM's someplace... I'll have to look around.

> > In OSProcess for Windows, I'm struggling with trying to implement
> > nonblocking pipes, and it's just plain ugly (I have something
> > working, but I'm still getting occasional Windows crashes in
> > testing). If there is a way to do a read with timeout on a Win32
> > anonymous pipe, please enlighten me before I embarrass myself
> > further.
> 
> Couldn't you just start another thread and do a non-blocking read on 
> the pipe, then signal a (Windows) semaphore? You could then do 
> WaitForMultipleEvents on all the semaphores...

That's similar to what I'm doing. Start a Win32 thread that does a
read, then Interpreter>>signalSemaphoreWithIndex when the read completes.
It works, but it's complicated and (pending further debugging) unreliable.
Debugging it frequently consists of turning off the computer, rebooting,
and trying something different. Grump.

Dave