Re: Asynchronous timers (without a run loop)
Re: Asynchronous timers (without a run loop)
- Subject: Re: Asynchronous timers (without a run loop)
- From: Jean-Daniel Dupas <email@hidden>
- Date: Fri, 5 Dec 2008 14:40:34 +0100
Le 5 déc. 08 à 13:52, Påhl Melin a écrit :
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...
The dotnet timer is useless for a lots of cases for one reason: "The
method does not execute on the thread that created the timer"
It uses a theadpool setup by the framework in background.
I really prefere the OS X approach that let you do something similar
in 5 lines of code, but is more flexible, as it also allow you to
execute timer on a predefined thread.
Now, you can request a wrapper API that create it's own thread, and
call a callback function on a random thread when it triggers, but I
doubt they will include it in Cocoa.
_______________________________________________
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