If I were trying to generate an asynchronous timer event in C I'd
probably just run a thread in a tight loop calling poll (man 2 poll
for details) each time round with a timeout equal to your timer
interval and no other events. And when the poll returns do whatever
processing you need on your timer.
Will that not work for you?
Otherwise your question seems to be "How can I use any of the high
level Mac OS X timer facilities without using the high level Mac OS X
timer facilities?" for which there is, of course, no answer.
On 4 Dec 2008, at 15:14, Påhl Melin wrote:
2008/12/4 Joseph Kelly <[EMAIL PROTECTED]>:
I've used both the CF and NS timer apis in many different
situations without
a hitch. They're fairly reliable. Perhaps you could explain your
"can't use
a runloop" restriction -- e.g. if you are writing a daemon or a
kext, this
is not the list you want to post to.
I'm not writing a daemon or a kext. I'm porting a framework that I've
designed and used on .Net before that will form the foundation of my
architecture for my future Mac OS applications (I'm new to Mac OS
programming). The framework is used for easy communication and
synchronization between threads, processes and computers (with the
same "syntax") and make it possible to design an application in small
modules that communicates via messages and it's straightforward to
start with the modules as threads in a single application and then
split into several processes on a computer or ever distribute certain
modules to other computers without changing much (or any) code at all.
But mainly it makes it easier to write efficient multithreaded
applications that "work".
I'm very happy with the messaging framework and would like to use it
on Mac OS X as well. Run loops are not compatible with this approach
since my threads need to run forever or block in my framework when
they are waiting for messages (the timers are used to generate timer
messages internally in the framework). The threads are not event
driven and will not return to the run loop.
You might find if you refactor your design a bit, that it will take
to a
runloop model quite well. In fact, most of the user space IOKit async
routines require that you use a runloop.
I don't "want to" refactor my design. :-) To do that, I would have
give up the framework design completely. I'm generally happy with the
design just want to make a good port to Mac OS X.
Also, the Mach APIs are not strictly private -- the headers are
publicly
available. They are subject to change between releases, so if you
do start
using them, you will need to stay on top of things -- check your
binaries on
pre-release OS seeds etc.
Okay, thats great to know. But I suppose it's still begging for
trouble, if you can avoid it.
Joe K.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/adc%40jeremyp.net
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
