Hi John--
Just to clarify: this issue is Win32-specific. The way Win32 signals changes of network socket status (data arrivied, other end closed, etc.) is through events that are placed in the window's event list. On other platforms, such notifications are handled in other ways, such as by using an asynchronous callback.
Did my previous message on this subject get through?
Win32s supports threads. For each socket, one could have a thread for reading/connecting, and a thread for writing, and use blocking procedure calls in each. The procedure calls themselves conform to the BSD sockets API (like the other platforms), and the thread overhead is small, whereas the win32s async stuff is unique and platform-dependent.
Why not do this?
thanks,
-C
-- Craig Latta composer and computer scientist Craig.Latta@NetJam.ORG www.netjam.org latta@interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]
At 10:28 AM -0800 3/23/98, Craig Latta wrote:
Hi John--
Just to clarify: this issue is Win32-specific. The way Win32 signals changes of network socket status (data arrivied, other end closed, etc.) is through events that are placed in the window's event list. On other platforms, such notifications are handled in other ways, such as by using an asynchronous callback.
Did my previous message on this subject get through?
Win32s supports threads. For each socket, one could have a thread for reading/connecting, and a thread for writing, and use blocking procedure calls in each. The procedure calls themselves conform to the BSD sockets API (like the other platforms), and the thread overhead is small, whereas the win32s async stuff is unique and platform-dependent.
Why not do this?
Well, it sounds like more work than just the few changes to the VM startup code that Tim R. suggested. It might be easy, but I'll let Andreas be the judge.
-- John
Here is significant question when using threads for the sockets:
Is it safe to call signalSemaphoreWithIndex without synchronized access?
I'd assume that it is unlikely to crash into any other accessors of it, but well if there are multiple network connections open (or any sound input/output) it _might_ happen. Looks like I have to build my own synchronization around this. Oh well, Craig you see that's the overhead one doesn't have if all is running in just one thread ;-)
Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Craig Latta -
Maloney