[Bug 956] HylaFAX faxgetty on FreeBSD taking 100% CPU

http://bugs.hylafax.org/show_bug.cgi?id=956


[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from [email protected]  2014-07-04 18:56 -------
Lee Howard responded as below. -d


It seems like a FreeBSD kernel bug to me.

The FIFO is deliberately opened by the process with non-blocking mode.  This
makes the read(2) return of 0 possible.

The process monitors the file descriptor of the opened FIFO with select(2) to
detect "to see if characters become available for reading" (quoting the
select(2) man page).  Because select(2) returns with an indication that the
FIFO has characters available for reading the process then attempts to read
those characters from the FIFO, but read(2) returns with 0 and no characters
read.  So it would seem that select(2) lied to us.

Fair enough, select(2) lied once, and the HylaFAX code can cope with that, but
then immediately select(2) lies to us again and again and hence the loop
continues endlessly because select(2) keeps telling the process that there is
data to be read from the FIFO when there really isn't.

It's possible that select(2) is getting tripped-up on the non-blocking mode of
the opened FIFO file.  After all, the old select(2) man page clarifies its
function "more precisely,  to see if a read will not block".  So if the file is
opened in a non-blocking mode then a read will never block and this
clarification leads us to conclude that select(2) is useless for files opened
in non-blocking mode.  However, this is simply a misunderstanding.  Later
versions of the select(2) man page further clarify that this explanation refers
to the scenario *if* the file had not been opened with non-blocking mode set. 
In other words, the non-blocking feature of an open file should never interfere
with the operation of select(2).

That's just a possibility.  I don't really know what the nature of the problem
is within the FreeBSD kernel.

The point is, though, that select(2) should not return with an indication that
the FIFO has data to be read when that really is not the case.

Another indication that this is a problem in the FreeBSD kernel is the
empirical evidence that this problem exhibits itself only with some, but not
all, FreeBSD kernels.

This bug sounds incredibly similar to those for which two configure-time
modifications were implemented previously: CONFIG_OPENFIFO and CONFIG_FIFOBUG. 
Comments in the configure script sum it up fairly well:

   #
   # Select the mode to use when opening FIFO files
   # in a server process.  One should be able to open
   # them read-only, but on some systems, select will
   # go into a loop when a client does a close.  This
   # problem can sometimes be avoided by opening the FIFO
   # read+write on the server side.  Otherwise, the
   # FIFO must be closed after each incoming message
   # which can lead to delays and/or lost messages
   # (though we try to compensate by doing some sleeps).
   #

So CONFIG_OPENFIFO=O_RDWR is used for the cases where it can "sometimes be
avoided".  CONFIG_FIFOBUG=yes is used for the others. The former is applicable
to many UNIX variants (not Linux).  The latter is applicable to at least some
Solaris versions.  BSD is never specifically mentioned in any of that, and so
it is treated as not requiring either workaround.

However, comment #8 on the FreeBSD bug 166071
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166071#c8) seems to indicate
that these workaround features are futile on the FreeBSD manifestation.

So as I see it we need either:

1) FreeBSD to fix the problem in the kernel, or...

2) Someone to tell us what to do in HylaFAX code to work-around the FreeBSD
select(2) bug.

Thanks,

Lee.


-- 
Configure bugmail: http://bugs.hylafax.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


____________________ HylaFAX(tm) Developers Mailing List ____________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe [email protected] < /dev/null