Re: Asynchronous timers (without a run loop)
Re: Asynchronous timers (without a run loop)
- Subject: Re: Asynchronous timers (without a run loop)
- From: David Springer <email@hidden>
- Date: Thu, 4 Dec 2008 09:01:47 -0700
I don't mean to sound patronizing, but unless I have missed some fundamental
premise, didn't you just re-invent DO? Maybe the right way to port this
framework is to make your API a thin wrapper on top of Obj-C messages, and
your set up a wrapper on top of DO setup. Just a thought.
- Dave.S
On Thu, Dec 4, 2008 at 8:41 AM, Jeremy Pereira <email@hidden> wrote:
> 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@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
>
--
http://go/OnlyCheckEmailTwiceADay - join the movement
_______________________________________________
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