In message <_A3351@delegate-en.ML_> on 07/04/06(00:06:11)
you "Xavier Cheney" <firstname.lastname@example.org> wrote:
| - Under linux, for each page access, I have two lines Xfwrite in the shell
|console (not in the log) like :
|  Xfwrite(1,19)=0, ferror()=1, errno=9
|  Xfwrite(1,274)=0, ferror()=1, errno=9
For each access for all pages? I can reproduce it in the access to
/favicon.ico in the server which does not provide it, or when a
client disconnected before receiving all of response data.
And the log will be in the LOGDIR/"stdout.log" file if you are
running your DeleGate in background.
Anyway this was the probe output for DeleGate/9.2.2 in which I observed
the SIGPIPE emulation for non-socket output on Windows.
It'll be removed in the next release and you can remove it in the
rary/file.c without side-effects in the current version.
9 9 Yutaka Sato <email@example.com> http://delegate.org/y.sato/
( ~ ) National Institute of Advanced Industrial Science and Technology
_< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller
(I'm writing the following as the memo. for myself:)
I put the message into rary/file.c in 9.2.2-pre4 as a probe to observe
and change the behaviour of fwrite() on Windows.
On Windows, fwrite(FILE) directed to a socket (which is emulated by
DeleGate because Win does not support stdio to a socket) does not return
error code 0 on output failure (in _write() in rary/windows.c),
although ferror(FILE) flags is turned 1.
Since fwrite() does not notify an error, relaying by DeleGate is not
stopped on an unexpected disconnection from the destination.
Thus it causes a rush of "SIGPIPE" messages in log, and possibly make
serious load by huge files of giga bytes.
So to detect reset by peer on Windows, I emulated fwrite()=0 on socket
reset by peer by Xfwrite(), seeing ferror() after fwrite().
The original problem is solved with this, but I left the probe to see
other possible problem, and forgot it. Then another problem was detected.
Typically this occures when unknown /favicon.ico is accessed which is
automatically subustituted by DeleGate with the default.ico of DeleGate.
Before the substitution, DeleGate skips the original response from the
server in 404 code. To do so, the output is redirected to NULLFP()
which is made of FILE *fopen(tmpfile,"r").
Writing to this FILE never succeeds and the output data is ignored lightly.
The file can be "/dev/null" or "nul" opened in "w" mode, but maybe I did it
with fopen in "r" mode to make it lighter and portable easily.
But it is (correctly) detected as an error in the probe for a test.
By the way, I found that writing to such FILE turns ferror()=1 on Linux but
ferror()=0 on MacOSX (and maybe on BSDs).