FIFO

[bernd@petrovitsch.priv.at (Bernd Petrovitsch)]

Hi!

On Don, 2012-11-29 at 09:07 +0000, Pietro Paolini wrote:
[...]
> Thanks for your reply, the fact is that I am not writing a device
> driver but just an user-space program  and I would like implement a

OK. Mailing on kernelnewbies@ suggests something else in my world;-)

>  technique like /proc/ under a normal directory.
> 
> Like /tmp/blahblah

> I have a program which take count about some statistics and I want
> read them "on demand" doing a cat of /tmp/blahblah, I investigate a
> bit and :
> 
> 1) FIFO can be a solution but if I am not wrong I need two FIFO, one
> for say "I want read stats" and another one where write them

Yes, named pipes (created with mkfifo(3) or mkfifio(1)) and unnamed
pipes (created with the pipe(2) sys-call) are a solution. And these
allow only unidirectional communication (if you want to keep it simple).
So just use 2 of them but that implies having 2 file descriptors on both
sides.

If you only want to read one bunch of data, than you do not need a
"command channel" since named pipes behave as follows: The first process
which opens the named piped blocks until a second process opens it.

So an implementation could be: You use a second thread which just opens
the named pipe and writes the current data to it if it is opened.
The "current data" needs locking anyways so separating that into a
second process needs shared memory, an mmap(2)ed file or the like to
transfer the data to the second one.
You can avoid the second thread/process with non-blocking I/O BTW.

But if it is that simple, the data collector can just dump the
statistics into a (new) plain file and atomically rename() it - if this
is timely enough.

So: If you have/want/need a command channel to say "I want to reads
stats", you need a second pipe (or other communication channel to the
collector - like e.g. signals or ...) anyways.
If you just want to `cat` the data from a "file", you cannot send such a
command anyways - at least not with `cat`.
Well, you can implement several pipes for several commands, data sets,
whatever ....

> 2) I could use inotify and write on a file the stats when file under
> monitoring is opened for read.

That smells like a race condition if the data collector writes into a
file in parallel with the reader. You would need a semaphore (or signal
or ...) so that the collector can tell the reader that is has finished.

> In both cases I need two file, I would like instead use one, how can I
> do that ?

The traditional solution is to use sockets (either TCP/IP or Unix
sockets) and you have your simple bidirectional communication with only
one file descriptor per process.

Given the application - one collects data, another one fetches it - the
collector can play the server role and the other one the client role.
but with sockets, you need netcat or socat(1) ....

Kind regards,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at