How is a Tcl server supposed to handle fulfilling multiple requests without blocking?

I'm a bit confused about how a Tcl server works. I've been coding a small version that works pretty well for my local application but I'd like to understand it better conceptually. I have Ashok Nadkarni's book and used it as a starting point and thought I understood the examples about how the server does not block. And, I went through some of the code from the tclhttpd3.5.1 server to get started (some months ago, now, and was using that general method of using state to repeatedly read until I was pointed to using coroutines).

I think my code has been working because one desktop application with very rapidly processed requests rarely has any issues of blocking. I thought all was correct because the previous session could be restored quickly even though multiple database requests are (or appear to be) processed concurrently.

My plan was to use a small number of web sockets to handle the SQlite database requests and use HTTP for any audio/video requests. (The application is like a digital study library.) When I started to code the audio parts to play, while leaving the rest of the UI active such that database requests could be made while it played, I started to wonder more about the way I structured it. I got it all to work for my particular case and, it likely, will handle everything quickly but I'd like to understand better.

I was stupidly thinking that the server just handles everything without ever blocking because it can handle multiple connections, but I put all my code in the same script as the server code. So, if I "fabricate" a blocking scenario, the server requests pile up but are eventually fulfilled. Although the server doesn't block, if one of the requests is time consuming, the program itself blocks until each request completes, apart from an exception like fcopy with -command option. I know that source can be used to break the script into component scripts but that doesn't make it non-blocking.

If one was going to use Tcl as a "real" server rather than just for one application, how are the requests to be processed without blocking each other? I mean are they to be executed as separate threads, separate child processes, separate interpreters? Maybe those three are almost the same, I don't know.

Should the server script call multiple instances of other scripts to fulfill the requests rather than calling procedures within the same "single-instance" script; and the operating system will process them as efficently as possible? But, if so, how is information shared between the processes? If two similar requests arrived at nearly the same time, could two spearate instances of the same script be loaded to fulfill the requests concurrently, such that one does not block the other?

In looking over the code in the tclhttpd3.5.1 server, it appears that, at times, he is using multiple interpreters and aliasing something; but I don't follow what's going one there.

I apologize for not knowing the proper terminology. Thank you for any guidance you may be able to provide.

One of the pieces of Tcl's low level implementation is an event loop. It allows it to wait for an event (typically a file descriptor becoming readable or writable, which covers a great many things, or a message from another thread) in the OS. In particular, it can wait for many file descriptors at once, and it can wait a defined amount of time (that's how timer events work). The implementation of these things isn't trivial, but the API surfaced by the event loop system is: you give a callback to be called when the event happens (with chan event or after), and the event loop implementation looks after the rest.

Things like the http package and chan copy and so on all build on this foundation.

The event loop in a particular thread is synchronous: it doesn't receive events when your code is actively doing something. Each thread will have its own event loop (not an important distinction until you use multiple threads).

There are three ways that the event loop may run:

1. Implicitly. This is how things work when you've got the Tk package loaded; when you get to the end of your script, the event loop is entered.
2. Explicitly with vwait (Tk's tkwait is a minor variation on this). In this case, you're running the event loop in waiting mode until the given variable is set (which fires a trivial C trace to set a flag that the outer waiting loop picks up; it's exactly as simple as it sounds).
3. Explicitly with update. In this case, you're running the event loop in no-waiting mode to consume events that have already become ready without actually waiting for anything. (update idletasks is a variation that only picks up idle events; idle events are things that are scheduled to happen only when there's nothing else to do, and are the core of Tk's Secret Sauce. They're not much used in non-Tk applications.)

It's not a good idea to run an event loop within an event loop. You can, it's not illegal or anything like that, but it tends to produce annoying bugs. Rewriting your code to avoid that (coroutines help!) tends to produce better code.

The other major part is non-blocking I/O, which Tcl supports on as many channels as it can (typically anything except an ordinary file, because your OS doesn't usefully support that either). When a channel is blocking, reads from and writes to it can block (i.e., take time to complete). When it is put in non-blocking mode, those reads and writes can instead fail to go through; typically you can ignore writes that fail that way as Tcl's default behaviour there is to just schedule the write to happen later, but for reads that means you can get a failure to read despite some data being available, and that's what chan blocked and chan pending give you a handle on.

The combination of an event loop and non-blocking I/O lets you do a lot of things with a single thread, and the only times when the single-threadedness will show up will be if you're doing lots of computation or the amount of I/O is getting really large. That's when you use multiple threads (with sending tasks into thread pools being a recommended approach for giving good manageability and resource usage control).