There is no reason not to use the default, non-blocking, behavior of PPS,
the documentation is a little is misleading saying blocking is preferred..
The only ramification is the usual impact of non-blocking fds namely that
you need to use select or ionotify to know when there is data to read but
that's it.  The first read from a regular PPS object will always return
its content irrespective of whether the object was opened blocking or
non-blocking, it's only subsequent reads that are affected.


On 2016-10-26, 1:47 AM, "Sesh" <community-noreply@qnx.com> wrote:

>Hello,
>
>We are using PPS to interface with QNX Wireless Framework. We prefer
>using the default non blocking behavior for PPS subscription. According
>to PPS manual ( Excerpt below ) it preferable to set FD to blocking. What
>are the ramifications of using non blocking fd's here?
>
>--------------  QNX PPS manual - Page 30----
>--------------------------------
>--Blocking and nonblocking reads--
>Reads to PPS objects are nonblocking by default, but the preferred method
>for querying PPS objects is to use blocking reads.By default, reads to
>PPS objects are nonblocking; that is, PPS defaults a normal open()
>to O_NONBLOCK, so that reads made by the client that opened the object
>don't block.
>The PPS default behavior when it reads is atypical for most filesystems.
>It's done this way so that standard utilities won't hang waiting for a
>change when they make a read() call on a file.For example, with the
>default behavior, you could tar up the entire state of PPS using the
>standard tar utility. Without this default behavior, however, tar would
>never make it past the first file opened and read.
>
>Setting PPS to block
>Though the PPS default is to open objects for nonblocking reads, the
>preferred method for querying PPS objects is to use blocking reads. With
>this method, a read waits until the object or its attributes change, then
>returns data.
>
>To have reads block, you need to open the object with the ?wait pathname
>open option, appended as a suffix to the pathname for the object. (For
>more information on the ?wait option, see Pathname open options (p. 40).)
>For example:
>€ to open the PlayList object for the default nonblocking reads, use the
>pathname:"/pps/media/PlayList"
>€ to open the PlayList for blocking reads, use the pathname plus the
>option: "/pps/media/PlayList?wait"
>A typical loop in a subscriber would live in its own thread. For a
>subscriber that opened the object with the ?wait option, this loop might
>do the following:
>/* Assume that the object was opened with the ?wait option
>No error checking in this example. */
>for(;;) {
>read(fd, buf, sizeof(buf)); // Read waits until the object changes
>process(buf);
>}
>Clearing O_NONBLOCK
>If you have opened an object without the ?wait option and want to change
>to blocking reads, you can clear the O_NONBLOCK bit, so that the
>subscriber waits for changes to an object or its attributes.
>30 © 2014, QNX Software Systems Limited
>Subscribing
>To
>clear the bit you can use the fcntl() function. For example:
>flags = fcntl(fd, F_GETFL);
>flags &= ~O_NONBLOCK;
>fcntl(fd, F_SETFL, flags);
>Or you can use the ioctl() function:
>int i=0;
>ioctl(fd,FIONBIO,&i);
>After clearing the O_NONBLOCK bit, you can issue a read that waits until
>the object
>changes.
>
>
>
>_______________________________________________
>
>OSTech
>http://community.qnx.com/sf/go/post117011
>To cancel your subscription to this discussion, please e-mail
>ostech-core_os-unsubscribe@community.qnx.com

Thanks Roger. 
Our SW architecture has a built in polling mechanism to wake up subscriber threads periodically. Based on your 
explanation it looks like we'll receive one or more messages during poll+read if publisher is active. I am not sure if 
publisher data will be buffered with message boundaries or overwritten.

Thanks,
Sesh