2013/6/7 John P. Rouillard <rou...@cs.umb.edu>
>
> In message <51b1957b.3020...@seb.ee>,
> Risto Vaarandi writes:
> >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.
>
> It has been a while but I seem to remember an issue with either pipes
> or unix domain sockets where an open would not return till the other
> end of the pipe/socket was connected. I think it was the reader that
> blocked but I am not sure.
>
> My concern is that this senario happens:
>
> writers to the pipe start writing and block when pipe fills
> sec opens and reads
> writers close the pipe and exits
> sec opens pipe but because there is no writer it blocks
> badness ensues
>
> from:
>
> http://www.unixguide.net/unix/programming/2.10.3.shtml
>
> looks like there is a noblock flag you can use to prevent this, so ti
> may not be an issue here since you can use the flag from perl (I
> hope).
>
in fact, if nonblocking mode is not used, both the reader and writer will
block, until consumer/provider of data will appear. This means that in
read-write mode the regular blocking open will always return immediately.
Also, I found that although POSIX does not encourage read-write opens, the
Linux man pages actually discuss this as a viable option. At this point, I
am actually thinking for adding support for both fifo handling modes which
can be set via a command line option.
kind regards,
risto
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
> ------------------------------------------------------------------------------
> 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
