POSIX FIFO/pipe

[Joel Sherrill]

Wei Shen wrote:
> Hi Joel,
>  
> I wrote several mails to you but got no reply for quite a few days. I 
> guess there must be sth. wrong. Maybe, my mails were recognized as 
> spams, so I try adding rtems-users...
I have not been at work much this week.  My wife had
surgery and this is the last week before school starts
for my kids.  So lots and lots of personal distractions.
>  
> On 7/26/08, *Wei Shen* <cquark at gmail.com <mailto:cquark at gmail.com>> wrote:
>  
> Thanks for the quick reply.
>  
> On 7/25/08, *Joel Sherrill* <joel.sherrill at oarcorp.com 
> <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>         1. POSIX says when pipe IO can be interrupted by signals. I
>         remember we think it is better to make FIFO/pipe independant
>         of POSIX API.
>
>     What is your blocking mechanism in the pipe code?
>     When blocking in RTEMS, you can specify an extra state bit
>     STATES_INTERRUPTIBLE_BY_SIGNAL.  So you can be blocking
>     on a mutex and that particular mutex API implementation may be
>     written to set the STATES_INTERRUPTIBLE_BY_SIGNAL bit.
>     When a signal occurs, that bit is checked.
>
>  
> I use semaphore and barrier. I just want barrier_wait to be 
> interruptible, but semaphore not.
> I do not quite understand what you mean. I do not find such interfaces 
> in barrier implementation. Do you mean I just need to set 
> STATES_INTERRUPTIBLE_BY_SIGNAL before barrier_wait and clear it after; 
> or barrier need hooking to check the state bit?
>  
I didn't know how you implemented it.  But it would be fairly 
straightforward to add
an attribute bit (part of object instance create) which specified 
whether the blocking
calls for that object instance would be interruptible.  This would have 
to be propagated
into the score initialize call for that object.

A good side-effect of this is that it would be possible to get EINTR 
from some
system calls (e.g read) since they are built upon Classic API calls.

We would have to decide if this attribute was only meaningful when the POSIX
API is enabled.  Since there are no POSIX signals otherwise, it does 
seem reasonable.
>
>         3. For anonymous pipes, it is easier to implement them as
>         FIFOs with arbitrary names. So what kind of paths is prefered
>         for pipes? 
>
>  
> Maybe, sth. like: /tmp/.pipe#id, where id is a 32bit integer?
>  
That sounds good to me as long as /tmp is created if it doesn't already 
exist.
>
>         BTW, I also found IMFS_memfile_write does not strictly follow
>         POSIX in that, it updates file ATime and MTime, while POSIX
>         requires file write to update MTime and CTime.
>          
>
>     Can you submit a patch and pointer to opengroup.org
>     <http://opengroup.org/>?
>
>  
Thanks.  Unless someone objects I will file a PR and apply this to the
open branches.
> http://www.opengroup.org/onlinepubs/009695399/functions/write.html
> "Upon successful completion, where /nbyte/ is greater than 0, 
> /write/() shall mark for update the /st_ctime/ and /st_mtime/ fields 
> of the file, and if the file is a regular file, the S_ISUID and 
> S_ISGID bits of the file mode may be cleared."
> (I have not checked the last sentence)
>  
> --- imfs.h.new  2008-07-25 14:20:27.000000000 -0700
> +++ imfs.h      2008-07-09 23:03:51.000000000 -0700
> @@ -196,12 +196,12 @@
>      _jnode->stat_ctime  = (time_t) tv.tv_sec; \
>    } while (0)
>
> -#define IMFS_mtime_ctime_update( _jnode )   \
> +#define IMFS_atime_mtime_update( _jnode )   \
>    do {                                      \
>      struct timeval tv;                      \
>      gettimeofday( &tv, 0 );                 \
>      _jnode->stat_mtime  = (time_t) tv.tv_sec; \
> -    _jnode->stat_ctime  = (time_t) tv.tv_sec; \
> +    _jnode->stat_atime  = (time_t) tv.tv_sec; \
>    } while (0)
>
> --- memfile.c.new       2008-07-25 14:19:38.000000000 -0700
> +++ memfile.c   2008-07-02 18:37:38.000000000 -0700
> @@ -844,7 +844,7 @@
>      copied += to_copy;
>    }
>
> -  IMFS_mtime_ctime_update( the_jnode );
> +  IMFS_atime_mtime_update( the_jnode );
>
>    return copied;
>  }
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985