On 28 January 2016 08:54, quoth Paul Mulligan: > When using multi-threading, such that the function which calls the > cyclic_task() is running in a separate detached thread from the main > thread, the pause function blocks forever and a signal is never > received as below. [...] > Also, I tried to use usleep() and sleep() instead of signals to wait for > the right time to call the cyclic_task(), but the timing is not right. It > seems that the sleeps can not wait longer than 10ms.
I assume you mean that they can't wait less than 10ms? clock_nanosleep should be able to wait a smaller interval (see the dc_user example), but you also need to set your process priority to one of the realtime ones (SCHED_FIFO or SCHED_RR) to get lower latency. If you want a really small latency, then you should use the non-generic network driver and a PREEMPT_RT kernel. If you want to continue using signals, you need to be aware that they're unthreaded -- a signal will by default wake up any particular thread, not necessarily the one you are expecting. To fix this and get signals to work in multithreaded programs, you need to make sure that you explicitly block the signal in all threads except the one that you're expecting to receive it. Or alternatively use a more modern timer API that's better suited to multithreaded applications. I suspect that overall signals or timers will produce worse performance than using a sleep, however. Also, you don't show what the implementation of your pause function is, but it's likely that unless you're taking care to use atomic variables or insert the appropriate barriers, the compiler is optimising something away to turn it into an infinite loop. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
