Candy wrote:How is this idea not just a display list, like OpenGL used to have before 2.0 - ie, it's been deprecated already! - or like any window manager since Windows 2.0 or so? Or like TCL/TK? Or dozens of other examples?
I don't think you get the idea here. This isn't a list in the sense of a pulldown menu; it wouldn't be visible to the user at all. It is a list in the sense of a collection such as an array or linked list.
Basically, the idea is that if an application is making several system calls (e.g., reading data from several configuration files), the program (or, more likely, the underlying library) would batch the system calls into a single call which would pass the list containing entries for each operation and its arguments, rather than making several calls in succession. The OS could then perform the series of operations without the overhead of repeated privilege and context switches.
By way of analogy, consider buffered I/O streams. Most I/O libraries buffer their operations in the application space, and will merge output operations on a single source into a single write until either the buffer is full, the application flushes or forces the buffer, or some operation dependent on the write is performed. Similarly, input functions will read a full buffer in on the first system call and pass data from that buffer until it is exhausted.
However, what Brendan is talking about is a more general facility which could be applied to any series of system calls, 'buffering' the calls themselves rather than the input or output. It is also less amenable to a purely automatic approach, but it can be at least partly automated, as Massalin showed.
A semi-manual version of this which could be exposed to the application developer might consist of creating a kind of 'system call transaction frame' in which system calls would be kept in abeyance until the last one is ready, similar to a transaction in some database systems, and could even be rolled back if some problem arose, in a way similar to an exception.
Code: Select all
transaction
{
system_call_x();
system_call_y();
if (foo)
{
system_call_z();
}
if (bar)
{
rollback bar_rollback();
else if (quux)
{
rollback quux_rollback();
}
else
{
system_call_w();
}
}
catch_rollback(rollback_bar)
{
}
catch_rollback(rollback_quux)
{
}
I don't know if Brendan actually had something like this in mind, but it does give some flavor of how it might be used in a higher-level language's syntax. There's no specific reason to have a special syntax for it, though it could prove useful.
