> >> Hmm.  If the messages are less than PIPE_BUF bytes long 
> (4096 bytes 
> >> on
> >> Linux) then the writes are supposed to be atomic.
> > Some of them involve long messages (>4K), but there are 
> many that do 
> > not (like the ones I had posted at the start of this thread).
> I checked around with some kernel/glibc gurus in Red Hat, and 
> the consensus seemed to be that we'd be better off to bypass 
> fprintf() and just send message strings to stderr using 
> write() --- ie, instead of elog.c doing
>             fprintf(stderr, "%s", buf.data);
> do
>             write(fileno(stderr), buf.data, strlen(buf.data));
> Anyone have any comments on possible portability risks?  In 
> particular, will this work on Windows?

Should work fine on Windows. fileno() is deprecated however, with the
following comment:
        C:\Program Files\Microsoft Visual Studio
8\VC\INCLUDE\stdio.h(688) : see
 declaration of 'fileno'
        Message: 'The POSIX name for this item is deprecated. Instead,
use the ISO C++ conformant name: _fileno. See online help for details.'

It still works, and there is a define to get around that warning though,
so it's definitly not critical.


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to