On Sat, Dec 28, 2002 at 10:01:07AM +0300, Borzenkov Andrey wrote:
[...]
What happens:
Another possibility is to push buffer back into output queue when write returns EAGAIN/EWOULDBLOCK. It has some potential of blocking output to a single destination, but then if destination cannot accept input anymore, it is probably broken anyway. Messages can be dropped on input side then (i.e. if queue is full, simply no new message is queued for this destination).
This was the indented behaviour and the patch I sent in my previous mail does this.
BTW it looks like syslog-ng makes writes in fixed 4096 buffer length. For pipes it is wrong - system guarantees atomic delivery of a single write up to PIPE_BUF; system is free to reorder parts of any single write with larger size. Portable way to query for PIPE_BUF on modern systems is to use (f)pathconf utility.
I don't understand you here. You mean that chunks of data written are reordered, or if there is multiple write()-s to the same pipe then those may get reordered? I've found this comment by googling though (it is a release notes of a rewritten pipe implementation for Linux): ---- * No single copy for exactly 4096 byte writes, only > PIPE_BUF. Single copy (and thus blocking) such writes could trigger bugs in user space apps that errorneously assume that a pipe write of PIPE_BUF bytes after a successful poll(POLLOUT) doesn't block even if O_NONBLOCK is not set. It's not defined in posix or susv2, but no unix version I tested blocks in such writes. ---- BTW: syslog-ng puts the pipe fd in nonblocking mode, so if the chunk is too large, write() should simply indicate that fewer bytes was written than originally asked to. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1