help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

piep/popen, was filesize of fifo


From: Daniel Heiserer
Subject: piep/popen, was filesize of fifo
Date: Thu, 01 Feb 2001 08:20:32 +0100

> The function stat('filename') will return size information, but that
> is not what you want.  It only tells you what the OS has buffered.
> If your libraries are caching reads then stat will give a smaller size
> than the number of bytes available to you.  Octave 2.1.31 is doing this.

I will flush always immediately after writing. so I see the current
size.

> Similarly, if your libraries are caching writes then stat will give a
> smaller size than the number of bytes you put into the fifo, and they
> will not be available on the other side.  In Octave 2.1.31, fwrite seems
> to be caching but fputs isn't.
> 
> The better way is to make the read-end of your fifo non-blocking:
>    fid = fopen("fifo", "r");
>    fcntl(fid, F_SETFL, O_NONBLOCK);
> It appears that O_NONBLOCK must be set immediately after opening.
> Note that the fopen call will block until the write-end has been opened.

that is my worst problem. Each side is blocked until the other side
opens.


what I do now is:
mkfifo fifo.1
mkfifo fifo.2

tee debug.i < fifo.1 | octave | tee debug.o > fifo.2

octave itself blocks until both fifo's are reopen by other
processes.

When I do all the stuff inside octave calling another octave this does
not clearly work. 
Is there a way around this blocking stuff?

Also I have no idea what i can do with octave's pipe function.
The popen also seems not satisfy all I need. (The "help" of it is wrong
anywany. And the mkfifo's in octave itself have mode-settings which
I do not understand)
something like perls open2 or open3 would be cool.
Does anybody know how this is implemented?



> Now you can do fread/fgets calls as normal.  However, if you ever run out
> of input, then Octave will think that you have encountered an end of file
> and will refuse to try to read any more.  As a workaround, you can close
> and reopen the file and it will work as normal (with only a 4 ms overhead
> on my Pentium 166), but this is ugly.  Anyone know what's going on?
> 

thanks daniel

Attachment: daniel.heiserer.vcf
Description: Card for Daniel Heiserer


reply via email to

[Prev in Thread] Current Thread [Next in Thread]