Re: cobalts printf thread affects signalfd operation
On 13.06.19 19:08, Lange Norbert via Xenomai wrote: Hello, I ran into a problem with the automatically spawned printf thread. Short summary: The kernel delivers signals by picking a thread that can accept a signal and does not mask the specific signal, only if none is available then the signal will be queued for asynchronous delivery. signalfd is asynchronous delivery, thus if one thread accepts signals then signalfd won't work as expected, enter cobals printf thread. Good point... Solutions would be: - Mask all signals for this thread (is there any downside?) I don't see any, we do not use signals for the operation of the printer. - Mask all signals on the main thread before calling xenomai_init. This is ugly, as that removes most methods of interacting with a hung startup. - Somehow mask the thread for signals later (only ugly solutions?). The first option would be a rather small patch: @@ -642,7 +642,11 @@ static void spawn_printer_thread(void) pthread_attr_t thattr; pthread_attr_init(&thattr); +sigset_t sset, oset; +sigfillset(&sset) +sigprocmask(SIG_BLOCK, &sset, &oset); pthread_create(&printer_thread, &thattr, printer_loop, NULL); +sigprocmask(SIG_SETMASK, &oset, NULL); } Looks reasonable, please send a patch (then it can still make into next stable). Jan -- -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
cobalts printf thread affects signalfd operation
Hello, I ran into a problem with the automatically spawned printf thread. Short summary: The kernel delivers signals by picking a thread that can accept a signal and does not mask the specific signal, only if none is available then the signal will be queued for asynchronous delivery. signalfd is asynchronous delivery, thus if one thread accepts signals then signalfd won't work as expected, enter cobals printf thread. Solutions would be: - Mask all signals for this thread (is there any downside?) - Mask all signals on the main thread before calling xenomai_init. This is ugly, as that removes most methods of interacting with a hung startup. - Somehow mask the thread for signals later (only ugly solutions?). The first option would be a rather small patch: @@ -642,7 +642,11 @@ static void spawn_printer_thread(void) pthread_attr_t thattr; pthread_attr_init(&thattr); +sigset_t sset, oset; +sigfillset(&sset) +sigprocmask(SIG_BLOCK, &sset, &oset); pthread_create(&printer_thread, &thattr, printer_loop, NULL); +sigprocmask(SIG_SETMASK, &oset, NULL); } Mit besten Grüßen / Kind regards NORBERT LANGE AT-DES ANDRITZ HYDRO GmbH Eibesbrunnergasse 20 1120 Vienna / AUSTRIA p: +43 50805 56684 norbert.la...@andritz.com andritz.com This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You
