Thanks for that. I've slept on it and I will go for a third option, storing all the content in a structure that looks exactly like the current "routing table" that stores all the PIDs, when it arrives, to avoid sending it as an argument via tell.
On Mon, Nov 3, 2014 at 5:20 PM, Alexander Burger <a...@software-lab.de> wrote: > Hi Henrik, > >> Today I tried a somewhat longer string of HTML at which point I got >> this: Tell PIPE_BUF > > Yes, there is a maximal length to 'tell' messages. Sorry, this should be > documented in the reference. > > It is the system-dependent constant PIPE_BUF, which used to be 512 bytes > on old Unixes, and is now e.g. 4096 bytes on Linux, or 5120 bytes on > SunOS (I just see, FreeBSD still seems to be 512 bytes). > > This is the size of the buffer in the kernel, and is the maximal amount > of data that can be sent atomically. > > "Atomically" is important here, because otherwise processes might block > when reading from the pipe(s). > > >> 1.) Use some other mechanism or change tell to allow for larger "payloads". > > Difficult for the above reason. > > >> 2.) Work around the issue, maybe something can be done with the fact >> that the protocol seems to allow for multiple frames to constitute a >> single payload (don't know if the browsers support this behaviour at > > Something like that sounds better. > > > BTW, 'tell' is used by 'commit' internally. Here we have no inherent > limit, because 'commit' takes care of that. And blocking is not an > issue, because other processes wait anyway for synchronization. > > ♪♫ Alex > > -- > UNSUBSCRIBE: mailto:firstname.lastname@example.org?subject=Unsubscribe -- UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe