\documentclass[]{article}
\usepackage{amsmath,graphicx,supertabular,hyperref,tabularx,ifthen}
\title{TIP \#374: Stackless Vwait}
\date{August 13, 2010}
\author{Thomas Perschak, Trevor Davel}
\urlstyle{sf}
\setlength{\parskip}{1ex}
\setlength{\parindent}{0pt}
\def\tipversion$#1${\texttt{\$#1\$}}
\def\tiplangle#1{\ensuremath{<}}
\def\tiprangle#1{\ensuremath{>}}
\def\tipbar#1{\ensuremath{|}}
\def\tipmail#1#2{\(\langle\){\small\expandafter\url{#1@#2}}\(\rangle\)}
\ifx\pdfoutput\undefined
\newcommand{\tipimage}[2]{\typeout{Make sure you download #1.eps}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.eps}}{\includegraphics[width=0.8\textwidth]{#1.eps}}}
\newcommand{\tipxref}[1]{}
\newcommand{\tipxrefend}{}
\else
\newcommand{\tipimage}[2]{\typeout{Make sure you create #1.pdf}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.pdf}}{\includegraphics[width=0.8\textwidth]{#1.pdf}}}
\pdfcatalog{/PageMode /UseOutlines}
\newcommand{\tipxref}[1]{\pdfannotlink attr {/C [0.5 0.5 1.0] /Border [0 0 1]} goto name {#1}}
\newcommand{\tipxrefend}{\pdfendlink}
\fi
\newenvironment{tipabstract}{\begin{abstract}}{\end{abstract}}
\begin{document}\maketitle
\begin{center}\begin{tabularx}{\linewidth}{|r@{: }X|}\hline
\textbf{TIP \#374}&\textbf{Stackless Vwait}\\\hline
Author&

Thomas Perschak \tipmail{tombert.group}{live.at}
\par
Trevor Davel \tipmail{twylite}{crypt.co.za}
\\
Created&Friday, \(\text{13}^{\text{th}}\) August 2010\\
Type&Project\\
Tcl Version&\(8.7\)\\
State&Draft\\
Vote&Pending\\
Version&\tipversion$Revision: 1.5 $\\
Post History&\\
\hline\end{tabularx}\end{center}
\thispagestyle{empty}\pagestyle{empty}
\begin{tipabstract}

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.
\end{tipabstract}
\tableofcontents\setcounter{page}{0}\clearpage\pagestyle{plain}

\section{Rationale}

Suppose you have three (or even more) synchronous procedures each of them waiting for the socket to be readable. This waiting is implemented with \textbf{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 \textbf{vwait} would block the procedure which called \textbf{vwait} first, till the last procedure has read all data.

The stackless \textbf{vwait} would allow to group all similar \textbf{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 \textbf{vwait} in a very elegant way. Currently the \textbf{vwait} command is last-in-first-out, on the basis of the stackless 8.6 core there could be an improvement to make the \textbf{vwait} command configurable as last-in-last-out or even completely stackless event driven.

\section{Specification}

This is only a first idea, but it could be similar to named-mutex definitions --- so one as to define the group of the \textbf{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:
\begingroup\small\begin{verbatim}
 vwaitgroup myvwaitgroup whoever-comes-first
\end{verbatim}
\endgroup

Finally comes the waiting for the \textbf{vwait} which is similar to the existing one:
\begingroup\small\begin{verbatim}
 vwaitnew<myvar>  myvwaitgroup
\end{verbatim}
\endgroup

In addition I would allow a timeout value to be specified:
\begingroup\small\begin{verbatim}
 vwaitnew<myvar>  myvwaitgroup<mytimeout>
\end{verbatim}
\endgroup

\section{Example}

This is only a very reduced example, but should show the principle of the problem:
\begingroup\small\begin{verbatim}
 proc myproc1 {} {
    open socket
    fileevent socket {set myvar 1}
    vwait myvar
    read data
 }
\end{verbatim}
\endgroup

Having more than one of these procedure above, the \textbf{vwait} would block data reading depending on the \textbf{vwait} stack.

The new stackless \textbf{vwait} would look like the following example: On a global level I would do the following:
\begingroup\small\begin{verbatim}
 vwaitgroup sockreadgroup whoever-comes-first
\end{verbatim}
\endgroup

Then the procedures:
\begingroup\small\begin{verbatim}
 proc myproc1 {} {
    open socket
    fileevent socket {set myvar 1}
    vwait myvar sockreadgroup
    read data
 }
\end{verbatim}
\endgroup
\begingroup\small\begin{verbatim}
 proc myproc2 {} {
    open socket
    fileevent socket {set myvar 1}
    vwait myvar sockreadgroup
    read data
 }
\end{verbatim}
\endgroup
\begingroup\small\begin{verbatim}
 proc myproc3 {} {
    open socket
    fileevent socket {set myvar 1}
    vwait myvar sockreadgroup
    read data
 }
\end{verbatim}
\endgroup

\vspace{3ex}\hrule\vspace{1.5ex}

\section{Comments}

Twylite 2010/08/17: ``coroutine-enabled event handling'' (\url{http://wiki.tcl.tk/21555}) presents pure-Tcl implementations of coroutine-enabled \textbf{vwait} and \textbf{gets} that do what this TIP describes without attempting to implement a custom scheduler.

\vspace{3ex}\hrule\vspace{1.5ex}

\section{Copyright}

This document has been placed in the public domain.

\section{Colophon}

\textit{TIP AutoGenerator --- written by Donal K. Fellows}
\end{document}
