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: Thu, 4 Dec 2008 16:14:09 +0100
2008/12/4 Joseph Kelly <email@hidden>:
> 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 (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