Re: Read FIFO blocked with gfortran (vs ifort)

[Jerry DeLisle <jvdelisle at frontier dot com>]

On 09/29/2010 07:42 AM, Tobias Burnus wrote:
=== snip ===
> b) Without GFORTRAN_UNBUFFERED_ALL= it stops already with
>    6/  8>              ** Creation Date: Wed Sep 29 15:33:01 CEST 2010
>
>    if (isatty (s->fd) || options.all_unbuffered
>        ||(options.unbuffered_preconnected&&
>           (s->fd == STDIN_FILENO
>            || s->fd == STDOUT_FILENO
>            || s->fd == STDERR_FILENO)))
>      raw_init (s);
>    else
>      buf_init (s);
>
> I wonder whether one should not also add "!is_seekable(s->fd)" to those
> items which are by default unbuffert.

I have looked this through.  The issue is unrelated to raw_init or buf_init 
above.  The issue is that we do not open files with O_NONBLOCK.  I can easily do 
that.

We need to decide under what circumstances we should open with O_NONBLOCK.  In 
the example, the first call to read (man 3) returns with 282 bytes. The next 
call to read is blocking and nevr returns, it is waiting for input.

I have ngspice set up here so I can explore all this further. Using O_NONBLOCK 
in unix.c, I get the folllowing:

$ ./a.out
   input.fifo opened
   output.fifo opened
 Fifo opened...
At line 81 of file spicy.f90 (unit = 10, file = 'output.fifo')
Fortran runtime error: End of file
$

So in this case with non blocking, the read returns right away with nothing and 
we interpret that as an end of file.

So what I think we need to do is special case FIFO.  I will give this some 
further thought and see if I can come up with a patch.  I have filed PR45839.

Jerry