John M McIntosh wrote:

> The 10ms delay (actually in the Socket code) is a workaround for the
>
> > semaphore timeout seeming to hang occasionally at least on Windows.
>
>
> >> This windows bug isn't more pronounced than before the refactoring,
> >> right? maybe this is resolved by Flow? (my understanding is that it
> >> is supposed to replace exactly that lower level, though I might be
> >> wrong...).
> >
> >
> >     Right. In my testing, using the (modular) primitive interface
> > provided
> > by Flow, no delays are necessary on any platform.
>
>
> I'd rather see the broken windows socket code rewritten/replaced before
> inserting odd bits of delay
> to work around the issue. Flow is a good idea, and if we are busy
> rewriting/refactoring the smalltalk code we
> should consider the use of Flow or fix stuff in the lower layer too?
>
> Not only FTP is affected but other applications that make use of high
> interrupt rates on a single socket for
> two-way communications are broken too on windows.

Totally agree.  I don't know the issues in the networking code so I 
won't presume to say whether it's possible but if it is then this would 
be really nice to see.  The mysql postgresql drivers, for example, have 
a 500ms delay inserted to make sure they work in Windows.  You can 
actually reduce it to about 80 (on my machine anyway) but it's still a 
big pain.

Julian

-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)