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: Thu, 4 Dec 2008 16:20:40 +0100
Le 4 déc. 08 à 15:50, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas <email@hidden>:
Le 4 déc. 08 à 15:17, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas <email@hidden>:
If you want to avoid Cocoa, Cocoa-dev is probably not the best
mailing
list
to ask.
You will have more chance on darwin-dev.
I don't want to avoid Cocoa, but I just haven't found any Cocoa
class
that supports timers without a run loop. But maybe I need to
switch to
darwin-dev.
What do you mean by "low-leve" ? What prevent you to use NS
classes ?
Is this contraint preventing you to use CoreFoundation ? (which is
low-level IMHO).
Nothing prevents me from using NS classes per se. I will use the
timers in a C++ class and want to get a callback to a normal
function—not calling a selector on an Objective-C class that most NS
classes would do. And since it's supposed to be the lowest level
of my
architecture I want it to be as efficient as possible.
The only problem I have is that I will run the timers on threads
without run loops so both NSTimer and CFRunLoopTimer (I didn't find
any reference information about CFTimer on ADC) are impossible to
use.
Of course, CFTimer was a shortened form for CFRunLoopTimer.
If you use timer, you need some primitive function that waits until
one
timer "trigger". I don't understand what is the difference between
waiting
using select, kevent,
or any other primitive and waiting using CFRunLoopRun(). All
threads have a
runloop (or create one when needed), so I really don't understand
what is
the problem here.
The difference is that my threads will not have any run loops. They
will run all the time or sleep on a blocking primitive in my
framework. Only Cocoa threads automatically have a run loop (my
interpretation). I will run my threads using the pthread library
directly so no run loops are created.
My understanding is that ALL threads have a runloop (from the
CFRunLoop doc):
«There is exactly one run loop per thread. You neither create nor
destroy a thread’s run loop. Core Foundation automatically creates it
for you as needed. »
As CoreFoundation is not part of Cocoa, I doubt that only Cocoa thread
can have a CFRunLoop. (In fact, I do not doubt, i'm pretty sure
CoreFoundation is based on pthread and do not use Cocoa at all).
I did tool that do not use obj-c at all and use pthread and CFRunLoop
to managed networks events (using CFSocket) and it works just as it
should.
For kevent, I'm surprised the doc say so, it look like it is
implemented (at
least in 10.4.11 and 10.5 XNU sources).
That's interesting. I will check it out. The man page is from april
14, 2000, so maybe Apple just forgot to update it.
If you want lower level primitive, you can use kevent's timers,
or if you
want really low-level, there is a mach timer API, but I don't
think it is
considere public as the header cannot be found in /usr/include/mach
In the man page for kevent it says that kevent timers are not
supported ("EVFILT_TIMER This filter is currently unsupported."). I
just assumed that the man page was correct and haven't made any
tests.
Are you sure kevent timers are implemented in Mac OS X? When it
comes
to Mach timers I wouldn't dare to use that in a commercial product
since Apple seems to ask developers to keep away from Mach.
Anyway, that's the API used in CoreFoundation for CFTimer and
declared in
mk_timer.h (see XNU sources for details). But I wont go this way
in a
shipping product.
Agree... I will keep away from any private API:s.
/ 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