From help-octave-request at bevo dot che dot wisc dot edu  Thu Feb  1 01:21:11 2001
Subject: piep/popen, was filesize of fifo
From: Daniel Heiserer <Daniel dot Heiserer at bmw dot de>
To: pkienzle at kienzle dot powernet dot co dot uk
CC: help-octave at bevo dot che dot wisc dot edu
Date: Thu, 01 Feb 2001 08:20:32 +0100

This is a multi-part message in MIME format.
--------------DF1A7093679619B2BE749BC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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
--------------DF1A7093679619B2BE749BC6
Content-Type: text/x-vcard; charset=us-ascii;
 name="daniel.heiserer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Daniel Heiserer
Content-Disposition: attachment;
 filename="daniel.heiserer.vcf"

begin:vcard 
n:Daniel;Heiserer,
tel;fax:41696
tel;home:1409782
tel;work:21187
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:daniel dot heiserer at bmw dot de
x-mozilla-cpt:;-3136
fn:Heiserer, Daniel
end:vcard

--------------DF1A7093679619B2BE749BC6--



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------