Am 12.07.2005 um 16:27 schrieb Tom Jackson:
On Tuesday 12 July 2005 06:28, Adam Turoff wrote:
On 7/11/05, Dossy Shiobara <[EMAIL PROTECTED]> wrote:
http://aolserver.com/wiki/ns_chan
Thanks. That worked like a charm. ;-)
This is interesting. I'll look at the source, but what happens in
the case of
an error during the time the thread has the channel? I know that
AOLserver
will detach the channel within the thread once the request is
finished, but
will it be returned to the pool? Is the channel protected with
either mutex
or wait variables?
I once tried to maintain an open channel per request thread for
IPC, but found
that AOLserver closes all channels after the request is complete. I
guess you
could use ns_chan to store the channel and associate the name to
the thread.
It is more efficient to get/put a channel with ns_chan as opposed to
opening/closing every time?
The *real* benefit of "ns_conn chan" is when you want to make a
socket server
in pure Tcl. There is a servicing thread which acts like a connection
hub,
which passes accept'ed connections to other servicing threads w/o
blocking the hub.
This is how AS is processing connection: the driver thread accepts
incomming
connections and passes the connected sockets to connection threads.
Hence, the
driver thread never blocks and is (almost) always ready to accept
(new) connections.
With "ns_conn chan" you can cook up your own custom Tcl socket server
if you like.
The threading extension also employs a simliar "channel transfer"
caps and there
is an example of a tiny socket-command-server and http-server written
in pure Tcl.
Both approaches are based on Tcl inherent capability of transferring
a Tcl channel
(which is a thread-bound thing) between distinct threads.
Look into the code... this is always a good idea.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
