Re: [Xenomai-help] Strange pipe behaviour

[Philippe Gerum <rpm@xenomai.org>]

Ignacio García Pérez wrote:
>>>1- rt_pipe_receive returns with r >= 0.
>>>2- /* whatever */
>>>3- Message is freed using rt_pipe_free.
>>>4- Next call to rt_pipe_receive returns with r = -EINTR.
>>>
>>>The only explanation I could come up with is that when the pipe is
>>>closed by the user mode process, the rt_pipe_receive tells the rt task
>>>by returning -EINTR. Is this right?.
>>
>>
>>Yes.
>>
>> According to the docs, -EINTR is
>>
>>
>>>only returned if rt_task_unblock() has been called...
>>>
>>
>>Actually, this is what happened through the internal interface.
>>driver::release(pipe) -> nucleus::unblock(sleepers_on_pipe)
> 
> 
> Sure, but that behaviour is *extremely* confusing for a newbie (like
> me). Should be described in the docs (this time I don't submit a patch
> because I don't quite understand the pipe internals yet).
>

If you understand enough of the API documentation to disagree with it, I guess 
that you should be able to reword it in a way that seems less error-prone in 
your eyes. You don't have to explain the gory details of the implementation to 
do that.

> And anyway, I don't see the point in notifying the RT task that the
> non-RT end has closed the pipe.

Message pipes are connection-oriented thingies. You cannot just let one 
communication end-point vanish and leave the other side lingering indefinitely 
without notifying it.

  Or, in other words, if we want to
> provide such a notification, we should provide also opening notification.
> 

That's irrelevant. rt_pipe_connect() from kernel space is semantically similar 
to open(some_named_fifo,O_RDWR|O_NONBLOCK) from user-space, since the caller 
does not wait for the other end-point to show up. But even in that case, closing 
the named fifo at the other side causes any subsequent read() on the connecting 
side to be notified of the closure. The same goes for message pipes. The only 
thing you could argue is that read() would first return a zero-sized message 
first as an end-of-file marker, then an error upon all subsequent reads; since 
we don't want to forcibly close the kernel side upon user-space closure, a 
possible change would be to make rt_pipe_recv() return -EPIPE instead of -EINTR 
in that specific case.

And actually, the nucleus interface does provide support for registering a 
connection notification handler, but it is not exported by the native skin since 
it would buy us nothing in the context of a regular API.

> By the way, where is the xnpipe_* API documentation? I could not find it
> in the online docs (firefox downloads the file search.php when I try to
> use the search feature).
> 

Still undocumented portion.

> 
>>>Nacho.
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Xenomai-help mailing list
>>>Xenomai-help@domain.hid
>>>https://mail.gna.org/listinfo/xenomai-help
>>>
>>
>>
> 
> 


-- 

Philippe.