Re: Asynchronous timers (without a run loop)
Re: Asynchronous timers (without a run loop)
- Subject: Re: Asynchronous timers (without a run loop)
- From: "Påhl Melin" <email@hidden>
- Date: Fri, 5 Dec 2008 13:52:46 +0100
2008/12/4 Julien Jalon <email@hidden>:
> The question itself does not make a lot of sense for me. A timer API is
> tightly bound to the underlying framework that is idling your thread.
> If the idling API is CFRunLoopRun(), you'd use CFTimers, if your idling API
> is select() or kevent(), you'd use their timeout parameters.
> So, for what you seem to say, it's your framework responsibility to provide
> some "asynchronous timer API". If it does not, your only choice is to
> simulate the timer using other means:
> - the easy one: one thread that sleeps() for each timer then messages back
> to your threads
> - a more complex one is to use a dedicated thread that will effectively run
> a CFRunLoop and bridge your timers over CFTimers.
> - you could imagine using signal() +SIGALRM bug using Unix signals here is
> really not something you should try to use except if you really know what
> you are doing.
The reason I asked for a simple Timer API without using a run loop is
because I'm converting my framework from Dotnet where such a Timer API
exists and makes it dead simple to setup multiple timers without
blocking or setting up a dedicated thread in each process for just
handling the timers. In C++/CLI using Dotnet you just specify:
Timer^ myTimer = gcnew Timer(gcnew TimerCallback(&TimerFunction),
nullptr, 5000, 500);
...to have the TimerFunction() function be called twice per second
after 5 seconds (time in millisecond). Nothing else – you don't need
to idle your thread at all. Dotnet handles everything by itself.
Setting up multiple timers is just repeating the line of code above.
(gcnew is just new on the garbage collect heap and the carret '^' is
just a pointer/handle to the garbage collect heap if you don't know
Microsoft C++/CLI)
Since it's so easy in Dotnet and Cocoa (plus the other API:s in Mac OS
X) is even more mature, I just assumed it would be just as easy in Mac
OS X. But it seems I was wrong. Of course, if you happen to already
use an event-driven design using run loops in Cocoa/Core Foundation
it's very easy here as well. But since I'm not...
Thanks everyone for giving me advice on setting up a separate thread
with a run loop (of any kind) to handle timers. It seem like the best
solution to make my own Timer API with a separate thread to simulate
the Dotnet Timer API. I just wish didn't have to. Maybe a feature
request for future Mac OS X releases...
/ Påhl
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden