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