Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2011-08-11 at 12:03 +0200, Philippe Gerum wrote:
> On Thu, 2011-08-11 at 11:37 +0200, Gilles Chanteperdrix wrote:
> > On 08/11/2011 11:10 AM, Philippe Gerum wrote:
> > > On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
> > >> Hello.
> > >>
> > >> I created a simple examples which describe my problem.
> > >> It is some kind of server and client.
> > >> At first run a qserver and then qclient.
> > >> After that close the qserver and try to run it again.
> > >> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
> > >> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.
> > > 
> > > That is the intended behavior. When deleted, the queue is maintained
> > > internally until the last client bound to it exits, which also disallows
> > > creating another queue with the same name until the latter event
> > > happens.
> > > 
> > > However, deleting the queue also makes it unreachable for further
> > > bindings, until it is completely dismantled after the last client exits.
> > > At which point you may re-create a queue with the same name and bind to
> > > it. Logically speaking, that deleted queue does not exist anymore,
> > > except for the currently bound client(s), for consistency reasons.
> > 
> > Maybe we could return -EIDRM instead of -EEXIST when in this case?
> > 
> 
> Not sure. EIDRM is conventionally about telling the caller that some
> previously valid identifier has been revoked while the operation was
> ongoing, which does not match the case of trying to establish a fresh
> binding to a zombie object.

Or trying to create a new object, the same way.

>  In the first case, we did have a valid
> object on entry, in the second one, that object has never been valid
> from the caller's standpoint.
> 
> I'm unsure that returning EIDRM would be trivial to implement anyway. We
> would have to make the registry layer aware of the "magic" tags used by
> the upstream interfaces, so that it could check atomically EIDRM vs
> EEXIST when failing to hash the object key. Granted, we could move this
> magic into the xnobject struct directly though and get rid of it
> elsewhere. Some work ahead in such a case.
> 

-- 
Philippe.