Stackless VwaitThomas PerschakTrevor Davel$Revision: 1.5 $
This TIP proposes a way to have multiple procedures waiting for an event to happen, where the command that gets executed depends on the order of the events.
Suppose you have three (or even more) synchronous procedures each of them waiting for the socket to be readable. This waiting is implemented with vwait - it is not possible to call this procedure event-driven - the socket is opened and closed inside the same procedure. The current implementation of vwait would block the procedure which called vwait first, till the last procedure has read all data.
The stackless vwait would allow to group all similar vwait calls, define them stackless as whoever-comes-first and so unblock the procedure which has first data to read.
Originally I thought this could be solved with coroutines but I'am not so sure any more. Anyhow I think that the problem - explained later below - could be solved with a stackless vwait in a very elegant way. Currently the vwait command is last-in-first-out, on the basis of the stackless 8.6 core there could be an improvement to make the vwait command configurable as last-in-last-out or even completely stackless event driven.
This is only a first idea, but it could be similar to named-mutex definitions - so one as to define the group of the vwait waiting for and the three behaviour types: first-in-last-out, first-in-first-out, whoever-comes-first;
The following command creates a new vwait group with a specified stack behaviour:
IHZ3YWl0Z3JvdXAgbXl2d2FpdGdyb3VwIHdob2V2ZXItY29tZXMtZmlyc3Q=
Finally comes the waiting for the vwait which is similar to the existing one:
IHZ3YWl0bmV3PG15dmFyPiAgbXl2d2FpdGdyb3Vw
In addition I would allow a timeout value to be specified:
IHZ3YWl0bmV3PG15dmFyPiAgbXl2d2FpdGdyb3VwPG15dGltZW91dD4=
This is only a very reduced example, but should show the principle of the problem:
IHByb2MgbXlwcm9jMSB7fSB7ICAgIG9wZW4gc29ja2V0ICAgIGZpbGVldmVudCBzb2NrZXQge3NldCBteXZhciAxfQ==ICAgIHZ3YWl0IG15dmFyICAgIHJlYWQgZGF0YQ==IH0=
Having more than one of these procedure above, the vwait would block data reading depending on the vwait stack.
The new stackless vwait would look like the following example: On a global level I would do the following:
IHZ3YWl0Z3JvdXAgc29ja3JlYWRncm91cCB3aG9ldmVyLWNvbWVzLWZpcnN0
Then the procedures:
IHByb2MgbXlwcm9jMSB7fSB7ICAgIG9wZW4gc29ja2V0ICAgIGZpbGVldmVudCBzb2NrZXQge3NldCBteXZhciAxfQ==ICAgIHZ3YWl0IG15dmFyIHNvY2tyZWFkZ3JvdXA=ICAgIHJlYWQgZGF0YQ==IH0=
IHByb2MgbXlwcm9jMiB7fSB7ICAgIG9wZW4gc29ja2V0ICAgIGZpbGVldmVudCBzb2NrZXQge3NldCBteXZhciAxfQ==ICAgIHZ3YWl0IG15dmFyIHNvY2tyZWFkZ3JvdXA=ICAgIHJlYWQgZGF0YQ==IH0=
IHByb2MgbXlwcm9jMyB7fSB7ICAgIG9wZW4gc29ja2V0ICAgIGZpbGVldmVudCBzb2NrZXQge3NldCBteXZhciAxfQ==ICAgIHZ3YWl0IG15dmFyIHNvY2tyZWFkZ3JvdXA=ICAgIHJlYWQgZGF0YQ==IH0=
Twylite 2010/08/17: "coroutine-enabled event handling" () presents pure-Tcl implementations of coroutine-enabled vwait and gets that do what this TIP describes without attempting to implement a custom scheduler.
This document has been placed in the public domain.