One interpreter/thread per connection? - tcl

Question

I want to write a server where people log in, send/type some commands and log out. Many persons may be connected at the same time, but I don't want to have a lot of state variables for each person, like "is sending name", "is sending password", "is in the second stage of the upload command"... It would be much easier to run one invocation of this script for each incoming connection:
puts -nonewline $out "login: "
gets $in login ;# check for EOF
puts -nonewline $out "password: "
gets $in password ;# check for EOF
while {[gets $in command] >= 0} {
switch -- $command {
...
}
}
Would memory and speed be OK with creating one interpreter per connection, even if there's about 50 connections? Or is this what you can do with threads?

Answer 1

A little bit of experimentation (watching an interactive session with system tools) indicates that each Tcl interpreter within a Tcl application process, with no additional user commands, takes somewhere between 300kB and 350kB. User commands and scripts are extra on top of that, as are stack frames (necessary to run anything in an interpreter). Multiplying up, you get maybe 17MB for 50 interpreter contexts, which any modern computer will handle without skipping a beat. Mind you, interpreters don't allow for simultaneous execution.
Threads are heavier weight, as Tcl's thread model has each thread having its own master interpreter (and in fact all interpreters are strictly bound to a single thread, a technique used to greatly reduce the amount of global locks in Tcl's implementation). Because of this, the recommended number of threads will depend massively on the number of available CPUs in your deployment hardware and the degree to which your code is CPU bound as opposed to IO bound.
If you can use Tcl 8.6 (8.6.0 is tagged for release in the repository as I write this, but not shipped) then you can use coroutines to model the connection state. They're much lighter weight than an interpreter, and can be used to do a sort of cooperative multitasking:
# Your code, with [co_gets] (defined below) instead of [gets]
proc interaction_body {in out} {
try {
puts -nonewline $out "login: "
co_gets $in login ;# check for EOF
puts -nonewline $out "password: "
co_gets $in password ;# check for EOF
if {![check_login $login $password]} {
# Login failed; go away...
return
}
while {[co_gets $in command] >= 0} {
switch -- $command {
...
}
}
} finally {
close $in
}
}
# A coroutine-aware [gets] equivalent. Doesn't handle the full [gets] syntax
# because I'm lazy and only wrote the critical bits.
proc co_gets {channel varName} {
upvar 1 $varName var
fileevent $channel readable [info coroutine]
while 1 {
set n [gets $channel var]
if {$n >= 0 || ![fblocked $channel]} {
fileevent $channel readable {}
return $n
}
yield
}
}
# Create the coroutine wrapper and set up the channels
proc interaction {sock addr port} {
# Log connection by ${addr}:${port} here?
fconfigure $sock -blocking 0 -buffering none
coroutine interaction_$sock interaction_body $sock $sock
}
# Usual tricks for running a server in Tcl
socket -server interaction 12345; # Hey, that port has the same number as my luggage!
vwait forever
This isn't suitable if you need to do CPU intensive processing and you need to be careful about securing logins (consider using the tls package to secure the connection with SSL).