X6 new socket interface?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

X6 new socket interface?

Griff-2
Reading the X6 documentation I see that X6 supports overlapped/threaded
socket calls to the underlying Windows API. Does this mean that
asynchronous socket calls are allowed (and are new to this release)?


Reply | Threaded
Open this post in threaded view
|

Re: X6 new socket interface?

Chris Uppal-3
Griff wrote:

> Reading the X6 documentation I see that X6 supports overlapped/threaded
> socket calls to the underlying Windows API. Does this mean that
> asynchronous socket calls are allowed (and are new to this release)?

If you mean the low-level asynchronous socket API (using select() or the
Windows extensions) then no -- that doesn't really fit with the stream-based
abstraction used by both packages.  If you want to use that API then you'll
have to extend the sockets package.

If you mean "can I read/write to the network from one Dolphin Process without
blocking the other Processes (such as the GUI) ?" then the answer is yes.  You
can do that with either sockets package -- only the implementations are
different.

In both implementations the Process that does a read will block, but other
Processes (including other network IO)  will continue to run.  The old package
implemented that by using a rather slow, and not always completely reliable,
Windows mechanism which translates the underlying network events into Windows
messages (see the methods of Socket in category 'event handling').  The new
implementation uses the more normal blocking reads and writes, but they are
implemented as "overlapped" external calls -- which means that Dolphin will use
a separate OS-level thread for the call.

In D6, each Smalltalk Process can be associated with an OS-thread, and that
thread (created automatically when it's first needed) will be used for all
overlapped calls.  (In D5 the threads were not bound to the Processes but were
just pulled at random out of a thread pool.)  That has the implication that
creating a lot of threads to act as workers for a networked program will create
similar numbers of OS threads -- and there is a limit to how many OS threads it
is sensible or efficient to use.

For reasonably small numbers of threads/Processes the new implementation is
usefully faster than the old (I think I once measured it at about 2x faster).
I don't know what happens if you do use lots (100s or 1000s) of parallel
Processes in either implementation; my /guess/ is that the new sockets package
would run, but with reduced performance (all those threads!), whereas the old
implementation wouldn't have that problem, but it would still be slow, and
reliability might be a problem.

    -- chris