[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
daniel.heiserer.vcf
Description: Card for Daniel Heiserer
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- piep/popen, was filesize of fifo,
Daniel Heiserer <=