Re: Asynchronous timers (without a run loop)
Re: Asynchronous timers (without a run loop)
- Subject: Re: Asynchronous timers (without a run loop)
- From: "Julien Jalon" <email@hidden>
- Date: Thu, 4 Dec 2008 17:15:53 +0100
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.
--
Julien
On Thu, Dec 4, 2008 at 4:14 PM, Påhl Melin <email@hidden> wrote:
> 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
>
_______________________________________________
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