Re: Possible race in pserver leading to broken pipe error?
Steve McIntyre writes: fsync() or fdatasync() should do what you want here. Although you _should_ be able to mix stream and fd operations normally - stdio is meant to do the right thing AFAIK. But now I can't find the reference I had that said so, of course. On the contrary, stdio expects to have exclusive control of the fd so you have to be very careful when that isn't the case to keep things from getting out of sync and producing undefined behavior. There's a discussion in the current Posix spec about the interaction and what you have to do to make things work right: http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_05.html In this particular case -- close()ing the fd underlying a stream -- there is at least one implementation where that causes the program to crash when the stream is later closed (either explicitly or implicitly when the program ends) which tries to close the fd again. -Larry Jones I've never seen a sled catch fire before. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
Derek Robert Price writes: It's been awhile since I played concurrently with descriptors and streams, but I thought I recalled that the only real issue was that they were using the same descriptor, so operations on one affected the other, as opposed to a dup() of a file descriptor, which keeps track of two sets of data about the file, two modes, two pointers, etc. On the contrary, dup() just gives you another handle to the same open file description -- the modes, pointers, etc. are *shared* by both fds. To get independence, you have to open the file again. -Larry Jones I can feel my brain beginning to atrophy already. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
Derek Robert Price writes: Okay... I had just made the assumption that all the descriptors would need to be flushed before close if one had, but I see what you are getting at now. The stdout stream had been used and has its own buffer so I needed to flush the stdout buf, and similarly the stderr buf, but not the descriptors. Just to reinforce the concept one more time (at the risk of beating a dead horse), descriptors don't have buffers and thus don't need to be flushed; *streams* have buffers and need to be flushed; closing a stream also flushes it. It's impolite at best to muck about with a stream's descriptor without at least asking its permission first. And it's highly impolite to take a descriptor away (by closing it) from a stream that's still using it. -Larry Jones This game lends itself to certain abuses. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_05.html Thanks. That was interesting. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAKmtgLD1OTBfyMaQRAjNZAJ0Z92G6rSl9UCGh3/Wk+y0SAb/iDQCfQxeh ID+cZyPbUK15MPgC8CkgSOc= =ZMl/ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: On the contrary, dup() just gives you another handle to the same open file description -- the modes, pointers, etc. are *shared* by both fds. To get independence, you have to open the file again. Except the close-on-exec flag isn't shared. And closing one dup'd file descriptor does not close the other. My man pages and what I could find via the recent opengroup link you sent, only list the close-on-exec flag as being maintained separately. Is there anything else? Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAKmzdLD1OTBfyMaQRAjyOAJ9dNvQ9ccvzlSF3Okpe6BEZ2ZDpggCg0Tr6 w9+3cRcLMcIS8WWMlM9HCJs= =XPFD -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: Just to reinforce the concept one more time (at the risk of beating a dead horse), descriptors don't have buffers and thus don't need to be flushed; *streams* have buffers and need to be flushed; closing a stream also flushes it. It's impolite at best to muck about with a stream's descriptor without at least asking its permission first. And it's highly impolite to take a descriptor away (by closing it) from a stream that's still using it. Okay, thanks. I think I have it now, except for the bit about dup(). Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAKmzoLD1OTBfyMaQRAmV1AJ0R2CjqAtMiej0Nith5cB8XRcwU4gCfdR4o CsNmHUOsJnHu3gWfsGG39Po= =hHqZ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
Derek Robert Price writes: Except the close-on-exec flag isn't shared. And closing one dup'd file descriptor does not close the other. My man pages and what I could find via the recent opengroup link you sent, only list the close-on-exec flag as being maintained separately. Is there anything else? I don't think so. -Larry Jones I don't like these stories with morals. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve McIntyre wrote:
On Mon, Feb 09, 2004 at 05:31:07PM -0500, Larry Jones wrote:
Steve McIntyre writes:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=24253
They had a similar problem with the Debian package, and the patch
listed on that page seems to fix it for them.
Thoughts?
My first impression is that it seems reasonable, but I'll have to give
it some thought. Note that the patch is defective, however: In the
definition of unset_nonblock_fd, the ``|'' should be ``''.
Hmm, yes. Of course it should. I'm a little curious as to how/why this
patch actually helps people now...
It may simply be that they put the patch in without being able to test
it because they couldn't reproduce the problem.
Anyhow, I think the diagnosis is correct. I added a fix to the buffer
close routines back in October 2002 due to a problem with server child
processes sending a SIGPIPE's instead of a SIGCHILD intermittantly. I
suspected a race condition but we could never nail down the cause. The
old log messages and discussions of the problem I just reviewed would
corroborate this theory exactly.
I've attempted to rewrite this patch, and attached it, still broken,
only because I may have to leave the office in a few minutes.
remotecheck is curerntly failing with this patch because STDOUT isn't
flushing, it looks like.
Derek
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.2336.2.176
diff -u -r1.2336.2.176 ChangeLog
- --- src/ChangeLog10 Feb 2004 19:54:59 -1.2336.2.176
+++ src/ChangeLog10 Feb 2004 21:37:42 -
@@ -1,5 +1,15 @@
2004-02-10 Derek Price [EMAIL PROTECTED]
+* server.c (do_cvs_command): Have the server child close all the pipes
+but the flow control pipe and wait on an EOF on the flow control pipe
+from the parent when done to avoid a race condition that could
+otherwise generate a SIGPIPE for the parent before the SIGCHILD when
+the other pipes were so full after a child exited that the parent
+attempted to write a stop byte to the flow control pipe.
+(Original report from [EMAIL PROTECTED].)
+
+2004-02-10 Derek Price [EMAIL PROTECTED]
+
* buffer.c (stdio_buffer_shutdown): Add a helpful comment.
2004-02-09 Derek Price [EMAIL PROTECTED]
Index: src/server.c
===
RCS file: /cvs/ccvs/src/server.c,v
retrieving revision 1.284.2.15
diff -u -r1.284.2.15 server.c
- --- src/server.c2 Feb 2004 15:12:11 -1.284.2.15
+++ src/server.c10 Feb 2004 21:37:46 -
@@ -2293,13 +2293,18 @@
# define SERVER_LO_WATER (1 * 1024 * 1024)
# endif /* SERVER_LO_WATER */
+
+
+/* Protos */
static int set_nonblock_fd PROTO((int));
+static int set_block_fd PROTO((int));
+
+
/*
- - * Set buffer BUF to non-blocking I/O. Returns 0 for success or errno
+ * Set buffer FD to non-blocking I/O. Returns 0 for success or errno
* code.
*/
- -
static int
set_nonblock_fd (fd)
int fd;
@@ -2314,8 +2319,29 @@
return 0;
}
+
+
+/*
+ * Set buffer FD to non-blocking I/O. Returns 0 for success or errno
+ * code.
+ */
+static int
+set_block_fd (fd)
+ int fd;
+{
+int flags;
+
+flags = fcntl (fd, F_GETFL, 0);
+if (flags 0)
+return errno;
+if (fcntl (fd, F_SETFL, flags ~O_NONBLOCK) 0)
+return errno;
+return 0;
+}
#endif /* SERVER_FLOWCONTROL */
- -
+
+
+
static void serve_questionable PROTO((char *));
static void
@@ -2792,11 +2818,33 @@
/* For now we just discard partial lines on stderr. I suspect
that CVS can't write such lines unless there is a bug. */
- -/*
- - * When we exit, that will close the pipes, giving an EOF to
- - * the parent.
- - */
buf_free (protocol);
+
+/* Close the pipes explicitly in order to send an EOF to the parent,
+ * then wait for the parent to close the flow control pipe. This
+ * avoids a race condition where a child which dumped more than the
+ * high water mark into the pipes could complete its job and exit,
+ * leaving the parent process to attempt to write a stop byte to the
+ * closed flow control pipe, which earned the parent a SIGPIPE, which
+ * it normally only expects on the network pipe and that causes it to
+ * exit with an error message, rather than the SIGCHILD that it knows
+ * how to handle correctly.
+ */
+/* Let exit() close STDIN - it's from /dev/null anyhow. */
+close (STDERR_FILENO);
+close (STDOUT_FILENO);
+close (protocol_pipe[1]);
+#ifdef SERVER_FLOWCONTROL
+if (set_block_fd (flowcontrol_pipe[0]) == 0)
+{
+ char junk;
+ while (read (flowcontrol_pipe[0], junk, 1) != 0);
+}
+/* FIXCVS: No point in printing an error message with error(),
+ * as STDERR is already closed, but perhaps this could be syslogged?
+ */
+#endif
+
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Robert Price wrote:
I've attempted to rewrite this patch, and attached it, still broken,
only because I may have to leave the office in a few minutes.
remotecheck is curerntly failing with this patch because STDOUT isn't
flushing, it looks like.
Yep, it just needed fflushes. Working patch attached. Comments before
I commit?
Derek
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.2336.2.176
diff -u -r1.2336.2.176 ChangeLog
- --- src/ChangeLog10 Feb 2004 19:54:59 -1.2336.2.176
+++ src/ChangeLog10 Feb 2004 21:56:50 -
@@ -1,5 +1,15 @@
2004-02-10 Derek Price [EMAIL PROTECTED]
+* server.c (do_cvs_command): Have the server child close all the pipes
+but the flow control pipe and wait on an EOF on the flow control pipe
+from the parent when done to avoid a race condition that could
+otherwise generate a SIGPIPE for the parent before the SIGCHILD when
+the other pipes were so full after a child exited that the parent
+attempted to write a stop byte to the flow control pipe.
+(Original report from [EMAIL PROTECTED].)
+
+2004-02-10 Derek Price [EMAIL PROTECTED]
+
* buffer.c (stdio_buffer_shutdown): Add a helpful comment.
2004-02-09 Derek Price [EMAIL PROTECTED]
Index: src/server.c
===
RCS file: /cvs/ccvs/src/server.c,v
retrieving revision 1.284.2.15
diff -u -r1.284.2.15 server.c
- --- src/server.c2 Feb 2004 15:12:11 -1.284.2.15
+++ src/server.c10 Feb 2004 21:56:54 -
@@ -2293,13 +2293,18 @@
# define SERVER_LO_WATER (1 * 1024 * 1024)
# endif /* SERVER_LO_WATER */
+
+
+/* Protos */
static int set_nonblock_fd PROTO((int));
+static int set_block_fd PROTO((int));
+
+
/*
- - * Set buffer BUF to non-blocking I/O. Returns 0 for success or errno
+ * Set buffer FD to non-blocking I/O. Returns 0 for success or errno
* code.
*/
- -
static int
set_nonblock_fd (fd)
int fd;
@@ -2314,8 +2319,29 @@
return 0;
}
+
+
+/*
+ * Set buffer FD to non-blocking I/O. Returns 0 for success or errno
+ * code.
+ */
+static int
+set_block_fd (fd)
+ int fd;
+{
+int flags;
+
+flags = fcntl (fd, F_GETFL, 0);
+if (flags 0)
+return errno;
+if (fcntl (fd, F_SETFL, flags ~O_NONBLOCK) 0)
+return errno;
+return 0;
+}
#endif /* SERVER_FLOWCONTROL */
- -
+
+
+
static void serve_questionable PROTO((char *));
static void
@@ -2792,11 +2818,36 @@
/* For now we just discard partial lines on stderr. I suspect
that CVS can't write such lines unless there is a bug. */
- -/*
- - * When we exit, that will close the pipes, giving an EOF to
- - * the parent.
- - */
buf_free (protocol);
+
+/* Close the pipes explicitly in order to send an EOF to the parent,
+ * then wait for the parent to close the flow control pipe. This
+ * avoids a race condition where a child which dumped more than the
+ * high water mark into the pipes could complete its job and exit,
+ * leaving the parent process to attempt to write a stop byte to the
+ * closed flow control pipe, which earned the parent a SIGPIPE, which
+ * it normally only expects on the network pipe and that causes it to
+ * exit with an error message, rather than the SIGCHILD that it knows
+ * how to handle correctly.
+ */
+/* Let exit() close STDIN - it's from /dev/null anyhow. */
+fflush (stderr);
+close (STDERR_FILENO);
+fflush (stdout);
+close (STDOUT_FILENO);
+fflush (fdopen (protocol_pipe[1], w));
+close (protocol_pipe[1]);
+#ifdef SERVER_FLOWCONTROL
+if (set_block_fd (flowcontrol_pipe[0]) == 0)
+{
+ char junk;
+ while (read (flowcontrol_pipe[0], junk, 1) != 0);
+}
+/* FIXCVS: No point in printing an error message with error(),
+ * as STDERR is already closed, but perhaps this could be syslogged?
+ */
+#endif
+
exit (exitstatus);
}
- --
*8^)
Email: [EMAIL PROTECTED]
Get CVS support at http://ximbiot.com!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
iD8DBQFAKVQ2LD1OTBfyMaQRAiHuAKC9AQc7kkqaVLHB/X1xEle0dZDAeQCggj6/
Lh8JPuu2Gr4UV6NN2GaytAg=
=5rDP
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
Derek Robert Price writes: Yep, it just needed fflushes. Working patch attached. Comments before I commit? fflush()/close() is a no-no -- you want fclose() instead. Once you've attached a stream to a file descriptor, you have to be very careful about what you do to the file descriptor -- it's best to only use the stream from then on. -Larry Jones I kind of resent the manufacturer's implicit assumption that this would amuse me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: Derek Robert Price writes: Yep, it just needed fflushes. Working patch attached. Comments before I commit? fflush()/close() is a no-no -- you want fclose() instead. Once you've attached a stream to a file descriptor, you have to be very careful about what you do to the file descriptor -- it's best to only use the stream from then on. Why, if you don't mind me asking? I couldn't find a man page for a file descriptor flush - is there some way I could have flushed the pipe without attaching the stream? Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAKXYPLD1OTBfyMaQRAtqfAKChnuPSxjBtk2SF8Vp0dRZSkD4iGACgmlWc oQpvy08L35KcaxY3ZUMNpbI= =554c -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
On Tue, Feb 10, 2004 at 07:23:43PM -0500, Derek Robert Price wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: Derek Robert Price writes: Yep, it just needed fflushes. Working patch attached. Comments before I commit? fflush()/close() is a no-no -- you want fclose() instead. Once you've attached a stream to a file descriptor, you have to be very careful about what you do to the file descriptor -- it's best to only use the stream from then on. Why, if you don't mind me asking? I couldn't find a man page for a file descriptor flush - is there some way I could have flushed the pipe without attaching the stream? fsync() or fdatasync() should do what you want here. Although you _should_ be able to mix stream and fd operations normally - stdio is meant to do the right thing AFAIK. But now I can't find the reference I had that said so, of course. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Into the distance, a ribbon of black Stretched to the point of no turning back signature.asc Description: Digital signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve McIntyre wrote: On Tue, Feb 10, 2004 at 07:23:43PM -0500, Derek Robert Price wrote: Larry Jones wrote: Derek Robert Price writes: Yep, it just needed fflushes. Working patch attached. Comments before I commit? fflush()/close() is a no-no -- you want fclose() instead. Once you've attached a stream to a file descriptor, you have to be very careful about what you do to the file descriptor -- it's best to only use the stream from then on. Why, if you don't mind me asking? I couldn't find a man page for a file descriptor flush - is there some way I could have flushed the pipe without attaching the stream? fsync() or fdatasync() should do what you want here. Although you _should_ be able to mix stream and fd operations normally - stdio is meant to do the right thing AFAIK. But now I can't find the reference I had that said so, of course. I tired fsync() and sync() originally and they didn't work. I just tried fdatasync() and it doesn't work either. Keep in mind that these are pipes and not files. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAKXtILD1OTBfyMaQRAp/OAKDfuPD+7TSn8XPOaC/BVLuTXP8lgwCfTaM4 Lb4uMQLVeK3YjuzSRxSbzfY= =w+d0 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
On Tue, Feb 10, 2004 at 07:46:01PM -0500, Derek Robert Price wrote: I tired fsync() and sync() originally and they didn't work. I just tried fdatasync() and it doesn't work either. Keep in mind that these are pipes and not files. Of course, yes. Doh! -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? signature.asc Description: Digital signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
On Tue, Feb 10, 2004 at 07:23:43PM -0500, Derek Robert Price wrote: Larry Jones wrote: fflush()/close() is a no-no -- you want fclose() instead. I couldn't find a man page for a file descriptor flush - There isn't one, especially not for pipes. AFAIK, as soon as you've written data into a pipe with write(), it's immediately available for read() without further (necessary or possible) action on your part. (For regular files there's fsync(), as already mentioned, but that's sort of different, in that the flushing it does is transparent to user processes under all normal circumstances; for sockets there's shutdown(), which looks sort of half-way between a flush and a close.) is there some way I could have flushed the pipe without attaching the stream? You mean protocol_pipe? It shouldn't be necessary. The buffer that fflush() flushes is only created by fdopen(), so the combination is a no-op. stdout and stderr, on the other hand, were already streamified, and presumably had data written to those streams, so those *do* need to be flushed -- but see below. All I think Larry's saying is, use 'fflush ... fclose' instead of 'fflush ... close'. The former sequence gives the userland stdio layer a chance to clean up everything it needs to clean up, whereas the latter sequence assumes that stdio has no cleanup to do in the first place. That might well be a correct assumption on many systems, but it's probably unsafe to count on it. In fact, I believe you could get away with just fclose()'s, with no fflush()'s at all. close() without fflush(), on the other hand, you know about... That is: fclose(stderr); fclose(stdout); close(protocol_pipe[1]); Two other comments: - Typo in the comment for set_block_fd() -- s/non-// * Set buffer FD to non-blocking I/O. Returns 0 for success or errno * code. - Maybe I'm being overly pedantic, but the last bit of new code, which drains flowcontrol_pipe, only does so if it succeeds in setting the descriptor to blocking mode. If that attempt fails, you could drain the pipe anyway; it'd be a busywait loop, but that seems safer than doing nothing. Something like this (untested): char junk; ssize_t status; while ((status=read (flowcontrol_pipe[0], junk, 1)) 0 || (status == -1 errno == EAGAIN)); -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Possible race in pserver leading to broken pipe error?
[ Initially sent to bug-cvs, but as other people have said, that seems to be dead atm... ] I've had this pointed out to me by a Debian user: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=24253 They had a similar problem with the Debian package, and the patch listed on that page seems to fix it for them. Thoughts? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? pgp0.pgp Description: PGP signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
Steve McIntyre writes: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=24253 They had a similar problem with the Debian package, and the patch listed on that page seems to fix it for them. Thoughts? My first impression is that it seems reasonable, but I'll have to give it some thought. Note that the patch is defective, however: In the definition of unset_nonblock_fd, the ``|'' should be ``''. -Larry Jones When you're SERIOUS about having fun, it's not much fun at all! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
On Mon, Feb 09, 2004 at 05:31:07PM -0500, Larry Jones wrote: Steve McIntyre writes: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=24253 They had a similar problem with the Debian package, and the patch listed on that page seems to fix it for them. Thoughts? My first impression is that it seems reasonable, but I'll have to give it some thought. Note that the patch is defective, however: In the definition of unset_nonblock_fd, the ``|'' should be ``''. Hmm, yes. Of course it should. I'm a little curious as to how/why this patch actually helps people now... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? pgp0.pgp Description: PGP signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
