2013/6/7 David Lang <da...@lang.hm>
> On Fri, 7 Jun 2013, Risto Vaarandi wrote:
>
> > hi all,
> >
> > recently, I have asked couple of questions about handling inputs and
> outputs,
> > but unfortunately have got not much feedback to them (maybe because of
> the
> > technical nature of these questions). Few days ago I was reviewing 10
> years
> > old code which handles named pipe inputs with some thoughts of slightly
> > modifying it.
> >
> > The users who have used named pipe inputs probably know that SEC keeps
> the
> > named pipe inputs open at all times, even when the writers disappear.
> > However, it is hard to achieve with a pipe opened in read-only mode,
> since
> > after all writers have closed the pipe, every subsequent read always
> returns
> > EOF, and calls to select(2) always indicate the availability of data. To
> fix
> > this issue, the pipe has to be closed and reopened.
> >
> > In the current code, SEC uses a slightly different approach -- it opens
> the
> > pipe in read-write mode, although in never writes into the pipe. However,
> > this guarantees that there is always at least one writer on the pipe, and
> > thus reopening is not needed. Nevertheless, recently I noticed in some
> man
> > pages that POSIX does not encourage opening named pipes in read-write
> mode.
> > Also, read-write mode has one small drawback -- SEC must have a
> > write-permission for the pipe, although this permission is of course
> never
> > used. This requirement must be therefore confusing to the users,
> although it
> > is explained in the FAQ.
> >
> > I'd like to ask a question from the users -- would you favor a change in
> the
> > named pipe handling and the use of the read-only mode, or do you think
> the
> > current approach is good enough? I would especially welcome comments
> from the
> > people with system programming experience. You can also reply to my
> private
> > e-mail, if you don't want to discuss the issue in the mailing list.
>
> I think that what we have is good enough. The gain from being able to have
> the
> pipe non-writeable by SEC is minor, and unless you have a different way of
> addressing the problems, the drawbacks from having the pipe always return
> EOF
> seems pretty significant.
>
...also, from the Linux man pages I've found a discussion on the advantages
of read-write mode. The EOF condition on the fifo can of course be easily
handled by closing and reopening the fifo which clears the EOF.
Nevertheless, if writing into a fifo involves closing it each after each
write (such as by calling 'echo mystring >fifo' from a shell script),
close-reopen is needed for each write operation which consumes extra CPU
time. In contrast, in read-write mode fifo can stay open at all times,
since EOF condition can never appear.
There is one special consideration, though, which made me to consider
adding read-only working mode to the code which can be activated through a
command line option (without this option, read-write mode would be used).
SEC also supports the --notail option which reads data from all inputs
until EOF, and if all EOFs have been reached, SEC will exit. Since for
read-write fifo EOF can never appear, the following workaround is used in
--notail mode -- if select() on fifo indicates the lack of data in fifo, it
is treated like end-of-data condition and fifo is closed. However, it would
be probably correct to expect the actual EOF from the writer. Of course,
one could argue that --notail option is almost always used with regular
files for testing purposes (in fact, no-one has complained so far about the
lack of the feature above).
Nevertheless, there is one possible improvement I can see here --
currently, in the --notail mode data processing for fifos and standard
input is done in the same code fragment. If for all pipe-like input devices
the semantics of --notail would change (terminate on actual EOF), this
would allow to ease some specific integrations. For example, if some system
would like to fork SEC and communicate with it through a memory-based pipe,
the system would not need to send TERM signal to SEC for shutting it down,
but it is enough to just close the pipe if SEC was started with the
--notail option. I acknowledge that the name "notail" is somewhat
misleading for such operating mode, since actually the SEC process could
stay on the pipe for long periods of time without seeing any input data. On
the other hand, this semantics could prove useful for some servers (for
example, rsyslog is not using TERM signals for taking down such forked
programs but only provides EOF through pipe).
Actually, I have already added few lines of code into the test version add
support for read-only fifo opens, retaining support for read-write opens
which remain the default. For switching between read-write and read-only
opens, --rwfifo and --norwfifo options can be used. Also, this has allowed
be to change the semantics of --notail option for all pipe-like inputs (in
--notail mode, --norwfifo has to be used).
How do you feel about it -- would you like to add some ideas and remarks to
the discussion?
And thanks for providing your feedback :)
kind regards,
risto
>
> David Lang
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
