Hi Randall,
> However: Questions back to Alex: How large are the atomic messages
> over pipes in picolisp, on average? I think you don't actually send the
> data over the pipe, but just block addresses in a DB have been updated. I
> am curious about this myself.
Yes, correct. Only external symbols (their names) are sent, which
directly encode the disk block offset.
The length of the message (in this case it is actually a _list_ of
external symbols) depends on the number of changes that happened during
a transaction. They may well involve thousands of objects for a large
update.
Therefore, 'commit' splits the whole message into chunks smaller than
PIPE_BUF. This can be seen, e.g. in the C version, in "src/io.c"
if (PipePtr >= PipeBuf + PIPE_BUF - 12) { // EXTERN <2+1+7> END
tellEnd(&pbSave, &ppSave, 0);
tellBeg(&pbSave, &ppSave, buf), prTell(data(c1));
}
And, as a result - if PIPE_BUF is small - this split happens more
frequently, and efficiency decreases.
Other applications which explicitly send data via 'tell' (not implicitly
like 'commit'), may even fail with an error message if PIPE_BUF is too
small, and the message is long:
static void putTell(int c) {
*PipePtr++ = c;
if (PipePtr == PipeBuf + PIPE_BUF - 1) // END
err(NULL, NULL, "Tell PIPE_BUF");
}
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
