Hello. I have couple of notices (or maybe errors) and questions 1) rt_mutex_acquire(...) causes now segmentation fault, when the mutex is not initialized with rt_mutex_create(...)
2) rt_queue_bind(&queue, TM_INFINITE) is not possible to interrupt by rt_task_unblock(...). See the qclient example from my previous message, where the signal handler is not able to unblock the main task. 3) Do you have any advice or idea how to create following scheme (or something similar): I have one server application which creates RT_QUEUE (and listens on it). Then I have couple of clients which binds to that queue (and possibly could send some request message to it from time to time). How to ensure the possibility to close the server and open it again? Because even if I don't call the rt_queue_delete(...) explicitly at the end of server, the result is perhaps the same (when server process finishs). Thanks in advance for any help. Best regards Petr Cervenka ______________________________________________________________ > Od: "Philippe Gerum" <r...@xenomai.org> > Komu: Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org> > Datum: 11.08.2011 12:06 > Předmět: Re: [Xenomai-help] rt_queue_bind() returns -EACCES > > CC: "xenomai-help" <xenomai-help@gna.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. > > > _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
