On 07/24/2015 05:29 PM, Philippe Gerum wrote: > On 07/24/2015 05:23 PM, Jan Kiszka wrote: >> On 2015-07-24 17:08, Philippe Gerum wrote: >>> On 07/24/2015 04:56 PM, Jan Kiszka wrote: >>>> On 2015-07-24 16:29, Philippe Gerum wrote: >>>>> On 07/23/2015 03:27 PM, Jan Kiszka wrote: >>>>>> On 2015-07-23 11:45, Philippe Gerum wrote: >>>>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote: >>>>>>>> On 2015-07-23 11:24, Philippe Gerum wrote: >>>>>>>>> >>>>>>>>> Hi Jan, >>>>>>>>> >>>>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or >>>>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code? >>>>>>>>> >>>>>>>> >>>>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the >>>>>>>> details. I'm currently not aware of a concrete scenario. It definitely >>>>>>>> makes sense to revisit this think. >>>>>>>> >>>>>>>> I guess one, if not the major problem back then was that the implicit >>>>>>>> malloc of the initialization step was not consistently causing a >>>>>>>> SIGDEBUG warning. That is now different. >>>>>>>> >>>>>>> >>>>>>> Since the current thread won't be notified until XNWARN is armed in its >>>>>>> TCB, any objection to move that call as a nop placeholder to the compat >>>>>>> section in libtrank, leaving the implicit init to libcobalt as >>>>>>> currently? >>>>>> >>>>>> Ack. >>>>>> >>>>> >>>>> Ok, let's see how deep you can dive into your context stack these days: >>>>> what about rt_print_cleanup() now? I see no in-tree callers, and I >>>>> wonder whether there is any use case for an application to stop the >>>>> stdio support during runtime. >>>> >>>> I used to have one recently that was specifically interested in >>>> terminating the associated thread. But that case was modified later on >>>> due to other reasons. In principle, the value of this cleanup function >>>> is in the printer thread control, even if that means cutting of wrapped >>>> I/O (you could still print via unwrapped services then). >>>> >>> >>> Ok. Was it part of a broader feature aimed at moving the per-process rt >>> support to a quiescent state? >> >> No, rather about ensuring that if you terminate only the main thread in >> an application that believes this thread was the last one, the >> application as a whole terminates. >> > > We could probably tell the existing atexit() handler to wipe the helper > thread too. >
mm, no. This would not exit, precisely. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
