I personally think that it is simpler to unify all IPC under a single SRR paradigm. The problem with rt-fifo's is that you have to treat them separately from the nameAttach/nameLocate paradigm. I think it would be a useful contribution to be able to view an RT thread as effectively a SIMPL "process". This could be used to handle certain classes of RTLinux problems quite nicely. I agree that an RT blocking "sender" thread would appear to have little use at first glance ... but there are many cases where the user process is a natural receiver. ie. it is blocking on messages from either other SIMPL processes, the keyboard, sockets or rt-fifo messages and handling all accordingly. Even though the rt-fifo messages are in discrete packets they are effectively banged together in a stream. In these classes of problems it is important to insure that the user space process operates fast enough on average to empty the steam ... using the rt-fifo as a buffer for fluctuations in user space timing. We have successfully used this technique for a voice over IP project. In the QNX world this kind of thing is often handled with a non blocking send called a proxy. Unfortunately to get data through the proxy method is often a two step affair. It would be nice to "have our cake and eat it too". rt-fifos are effectively non blocking sends with message content. What if we were to implement the non blocking send in a similar manner to the non blocking receive? The user space reply would then come in asynchronously to the RTLinux side ... but that could still be useful. At 06:53 PM 3/17/00 -0500, you wrote: >SIMPL - http://www.holoweb.net/~simpl > > >Hi folks, > >I looked at the rt-linux implementation of rt FIFO's for communication >between rt-linux threads and user space today because I recall >some interest in SRR and rt-linux. The fifo implementation is tiny >and trivial, but I'm left wondering if its worth it. We have three different >IPC possibilities here. > >1 - SRR between rt-linux threads. Given the tiny size/weight of rt-linux >threads I don't see why this would be useful. If it was, it could be >implemented trivially as simple wrappers around semaphores since >the threads can access each others data already. > >2 - Send from rt-linux to user-space. Why a rt task would willingly block >on a non-rt task is beyond me. This is useless. > >3 - Send from user-space to rt-linux. More interesting. > >On the rt-linux side it could do a name_attach(), then when it gets >asynch notification of data availability (much like the FIFOs work), >the thread could do a Receive() (which would never block). It >could then do a Reply() of data back to user space whenever it >wants. The u-space process would be blocked on the rt-thread >until the reply occurs, and of course reply never blocks. Trigger() >(which is also non-blocking) could also be implemented. > >So we have here a rt-linux task that from the user-space client process >is indistinguishable from a user-space server process, it just does >a name locate, and starts making requests. Sounds fine. > >--------- >Summary of rt-linux support (easily) possible: >qnx_name_attach() >Receive() (but it will never block...) >Reply() >Trigger() > >To the user-space client, rt-linux would look like anything else. > >--------------- > >But why? > >It's trivial to use the FIFO's to talk to a rt-linux task, so I'm not sure >what you'd gain here. > >Does anybody have any comments? Reasons why this would be worth >my time implementing? I seem to recall some traffic on this list suggesting >it might be worth it. > >Sam > > >______________________________________________________________________ >To unsubscribe, write to [EMAIL PROTECTED] >______________________________________________________________________ >Start Your Own FREE Email List at http://www.listbot.com > > Robert D. Findlay Senior Software Engineer FC software Inc. Tel: (905)659-0512 email: [EMAIL PROTECTED] Web: www.netcom.ca/~fcsoft -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
