On 2011-10-19, Rich Felker <[email protected]> wrote:
> On Wed, Oct 19, 2011 at 02:24:49PM +0000, Grant Edwards wrote:
>> On 2011-10-19, Rich Felker <[email protected]> wrote:
>> > On Tue, Oct 18, 2011 at 08:42:52PM +0000, Grant Edwards wrote:
>> >
>> >> For now, I'm rewriting the code to use SIGEV_SIGNAL.
>> >
>> > If you want thread delivery, it would be easiest to just make a thread
>> > that enters a loop calling clock_nanosleep to sleep until the next
>> > intended wakeup time then calls your callback function...
>>
>> That would be a lot of wheel-reinventing. I don't really feel like
>> re-implementing an entire timer subsystem with a sorted-list of timer
>> intervals and functions to insert/remove/set/reset/enable/disable
>> timers.
>
> I would just do a dedicated thread for each time and no management
> structures. Let the kernel manage it for you.
Ah, yes -- that would be pretty simple. I misunderstood your
suggestion, and though you were suggesting a single thread that
handled all "timers". Creating a thread per timer would be much
easier. I'll keep that approach in mind for next time I run into this
problem.
>> It's way simpler to use SIGEV_SIGNAL and then set up a thread that
>> calls sigwaitinfo() in a loop waiting for the timer signal. The
>> kernel's quite good at keeping track of timers and figuring out when
>> the next one times. :)
>
> That works, as long as you block the signal in all other threads.
Yes: all threads have the signal blocked, and one thread calls
sigwaitinfo() to wait for that signal. This has the advantage that
there is no thread-creation going on once things are all set up and
running. Thread creation probably isn't that big a deal, but the
painful memory of process-creation overhead on VMS never really goes
away...
> I was worried about async signal safety issues, which don't come into
> play with your approach.
--
Grant Edwards grant.b.edwards Yow! I'm a nuclear
at submarine under the
gmail.com polar ice cap and I need
a Kleenex!
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
