On 25/12/2007, Igor Stasenko <siguctua at gmail.com> wrote:

> Sockets are managed by socket plugin and keep own, private separate
> list for each interpreter instance.
> You may pass it, but if you try use it with other interpreter, which
> creates it, all primitives will fail.
> This can be changed however, i see good reasons why socket handles can
> be passed between images.
>

On second thought, i say no. There is many concurrency issues arising,
when two (or more) independent interpreters trying to work with same
socket handle.
Of course OS sockets are thread safe, but structures, assigned to them
for serving ST side, like semaphores, mutexes and different state vars
are unique and should be accessed synchronously.

However, its very easy to write few additional primitives which tell
socket to redirect all incoming data to specified channel, and also
make socket to behave like a channel which listens for data.

Since sockets (at least in windows) using own thread, there is no real
difference, where to pass data - in channel or to some buffer. And
speed degradation should be minimal (if it will be at all).

Also, erasing differences between channels and sockets having many
benefits - common interface, simple use.
Currently channel features is not very mature, and i'm already don't
like some of their current functionality.
I thought it was a good idea to have named channels. It's much more
convenient for developer to use names instead of port numbers to
identify them. But channel discovery mechanism needs more thought.
well, this is only preliminary design and use cases will show us what
need to be changed.

There are already some variants, which i would like to see for
channels: like using staticaly allocated buffer queue, so writing to
channel will not require memory allocation for buffer and freeing it
upon receipt.
Also, its possible to pull data from channel in 'hot' manner - without
waiting semaphore. So,  for heavy data throughput tasks or for a fast,
realtime reacting on events, you can create at process which will
constantly pulling data from channel without waiting on semaphore.


-- 
Best regards,
Igor Stasenko AKA sig.