Tom Jackson wrote:
David Walker wrote:

I want to support a reasonable number of concurrent connections.  I am
running
a tcl based SMTP filter/server based on the smtpd in tcllib.  I am
converting
it to run within AOLServer.

Can ns_socklistencallback push the conn to another thread or will I
have to
use ns_socklisten, ns_sockaccept, and ns_thread?

I thought that ns_socklistencallback provided a separate thread for each
connection, maybe that isn't true, but it should still be able to handle
multiple connections at the same time. Did you do testing that indicated
otherwise?
It does not unless you patch it. I have my AOLserver (3.4.2-dq4) patched
against that (and switched Tcl to 8.3.4). It is available from
www.dq-e.com/aolserver/ in case somebody's interested.

If you really need separate processing threads, I have used two
threadpools, using Rob Mayoff's dqd_threadpool module.
From what I've tested, it looks like ns_thread begindetached actually
grabs available threads from the pool... So using thread 2.5 (once Zoran
gets it done) to implement thread pools inside AOLserver would be like
reinventing the wheel.

I even tested it with gdb+nscp:
dq:nscp 1> time {ns_thread begindetached {ns_sleep 1}; ns_sleep 2} 10

And gdb running 'dq' AOLserver did not notice any new threads.

The thing I miss most, however, is that there is no SSL equivalent that
would be creating threads on every accepted connection.

One pool is for
worker threads, and one (with one thread) serialized access to a single
fd. You have multiple fds, so you probably don't need the second pool.
Actually, why the second pool? I once used a master thread and slave
threads.

I hope, someday, we will have a module that generalizes the ns_conn
module: allowing optional url support, but not specific to the http
protocol. For lack of a better name I'm using ns_tcp and ns_udp. So the
day someone invents the next great protocol, AOLserver will be the
programming environment of choice.
Dream on ;-)

--
WK
(written at Stardate 56909.3)

"Data typing is an illusion. Everything is a sequence of bytes."
                                                             -Todd Coram

Reply via email to