On Thu, 2009-11-05 at 02:46 +0100, Gilles Chanteperdrix wrote: > Peter Soetens wrote: > > Hi, > > > > I'm creating my RT threads using the native API and I'm creating > > mqueues, wrapped to the pthread_rt library. > > I can read and write the mqueue (and it goes through Xenomai), but > > when I select() on a receiving mqd_t, the select() calls returns that > > there is data available on the mq (it fills in the FD_SET), but keeps > > doing so even when it's empty (the select() is in a loop). Also, it's > > modeswitching like nuts. > > > > I found out that the __wrap_select is correctly called, but returns > > -EPERM. Kernel sources indicate that this is caused by > > pse51_current_thread() alias thread2pthread() returning null. Since > > EPERM is returned to userspace, the __real_select is called from user > > space, causing the mode switches and bad behaviour. This is almost > > certainly the thing that native + RTDM + select() is seeing too. > > > > My mqueues-only work probably because mq.c only uses > > pse51_current_thread() in the mq_notify function. I'm guessing that > > mq_notify would also not work in combination with native skin. > > > > I had two options in fixing this: add a xnselector to the native task > > struct or to the nucleus xnthread_t. I choose the latter, such that > > every skin kan use select() + RTDM and migrate gradualy to the RTDM > > and/or Posix skin. > > I needed to free the xnselector structure in xnpod_delete_thread() , I > > chose a spot, but it causes a segfault in my native thread (which did > > the select) during program cleanup. Any advice ? Also, maybe we should > > separate select() from the posix skin and put it in a separate place > > (in RTDM as rtdm_select() ?), such that we can start building around > > it (posix just forwards to rtdm_select() then). > > > > A second patch was necessary to return the timeout case properly to > > userspace (independent of first patch). > > > > Tested with native + posix loaded and mq. If you never quit your > > application, this works :-) > > Hi, > > I have included a lightly modified version of this patch on head, I do > not see any crash. However, I have some doubts about the current > implementation: calling xnselector_destroy() opens opportunities for a > rescheduling, which I am not sure is really what we want in the middle > of xnpod_delete_thread(). Philippe, what do you think? >
Same as you do: that would break. > Regards. > -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
