On Wed, May 23, 2012 at 12:45:19PM +0200, Ole Tange wrote: > If I read the code correctly it costs nothing to set the maximum block > size to max of 64-bit integer.
It costs nothing, but it won't work and it's not useful: It won't work because you'll get integer overflows this way. It's not useful because the kernel shared memory limit is typically much lower (e.g. 32MB on x86), so the subsequent shmget() call will simply fail. And I also fail to understand why the maximum block size is important. Does it really hurt if buffer splits writes to multiple blocks? > The 64-bit limit might not work on all systems, but I find it > ridiculous that it is 'buffer' and not the system that sets the limit. Well, buffer tries to prevent the user from doing unreasonable things. Hint: There's no limit in buffer for the maximum shared memory size, so this is what you probably want to modify using -m. But this way, you'll sooner or later hit the system limit. > It seems 'mbuffer -q' can be used instead, but it seems to be slower > than 'buffer'. With -t it does memory mapped temporary files. Temporary files don't seem like such a clever idea to me. I'd try anonymous shared memory or simply threads with a common address space. But that effectively means a complete rewrite of buffer. Martin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
