Pondering a "threadless" VCL execution model

[Nils Goroll]

Hi,

as many of you reading this will probably know, a colleague and me have been 
working on async I/O for Vinyl Cache for ~2 years and we are going to publish 
what we have this year.

The following concerns the client side only.

The model we are following so far is basically one I/O thread per core, which 
can be thought of the acceptor and waiter combined, plus doing most of the I/O. 
When VCL needs to run, the I/O thread would dispatch the req parsing and VCL FSM 
to run on a worker. This would ultimately call the transport's vtr_deliver_f, 
which would return VTR_D_DISEMBARK to leave the actual delivery with the I/O thread.

The reason to switch to a worker thread is that VCL could do anything, in 
particular block on I/O, and we certainly would not want the I/O thread to halt 
neglect other work just because some vmod calls sleep(10).

Now this is all good and well, except that the thread switching has a cost, and 
there are many cases where VCL never blocks. And, obviously, for these cases not 
dispatching VCL and running it in the I/O thread would be more efficient.

Also, at the moment, we might still block waiting for a backend thread, but 
handling this differently does not look like a relevant problem.

I have been pondering ideas on and off how we could achieve to keep the 
dedicated worker thread for VCL if/when we need it, and get rid of it where we can.

The obvious way would be for vmod functions to announce "I will block" when they 
do, and core code would implement some kind of "coroutine" context swapping 
using swapcontext. This looks to me like the right solution, but it comes with 
complexity and potential pitfalls, like if Thread Local Storage is used.

The other idea is just to have VMODs announce globally that they "need a thread" 
(or maybe the inverse, rather). This way, as soon as a VMOD using blocking I/O 
was imported, processing would switch from "single worker" to "dedicated 
thread". I am skeptical about this idea, because it might render the whole 
optimization useless in practice.

Now my question is if anyone has any better ideas on this?

Nils

--

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260819/fd9e8a1c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260819/fd9e8a1c/attachment-0001.bin>