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.
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===