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. 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. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
