Le 6 déc. 08 à 00:22, Påhl Melin a écrit :
2008/12/5 Sherm Pendley [EMAIL PROTECTED]:
On Dec 5, 2008, at 3:16 PM, Påhl Melin wrote:
2008/12/5 Sherm Pendley [EMAIL PROTECTED]:
You'd have far, far less trouble programming for the Mac if you'd
simply
learn how Cocoa works, instead of
2008/12/4 Julien Jalon [EMAIL PROTECTED]:
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
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
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
2008/12/5 Jean-Daniel Dupas [EMAIL PROTECTED]:
The dotnet timer is useless for a lots of cases for one reason: The method
does not execute on the thread that created the timer
It uses a theadpool setup by the framework in background.
In my case, I have no need at all, to run the callback from
Le 5 déc. 08 à 13:52, Påhl Melin a écrit :
2008/12/4 Julien Jalon [EMAIL PROTECTED]:
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
2008/12/5 Benjamin Stiglitz [EMAIL PROTECTED]:
I need to use timers in a low level library where I need to specify
asynchronous callbacks to a timer function. I will not have any run
loop so I cannot use NSTimer. Are there any low level timer API to use
instead? I haven't found anything useful
On Fri, Dec 5, 2008 at 7:52 AM, Påhl Melin [EMAIL PROTECTED] wrote:
The reason I asked for a simple Timer API without using a run loop is
because I'm converting my framework from Dotnet where such a Timer API
exists and makes it dead simple to setup multiple timers without
blocking or setting
On Dec 5, 2008, at 7:52 AM, Påhl Melin wrote:
...to have the TimerFunction() function be called twice per second
after 5 seconds (time in millisecond). Nothing else – you don't need
to idle your thread at all. Dotnet handles everything by itself.
Setting up multiple timers is just repeating the
Le 5 déc. 08 à 16:00, Påhl Melin a écrit :
2008/12/5 Benjamin Stiglitz [EMAIL PROTECTED]:
I need to use timers in a low level library where I need to specify
asynchronous callbacks to a timer function. I will not have any run
loop so I cannot use NSTimer. Are there any low level timer API to
2008/12/5 Jean-Daniel Dupas [EMAIL PROTECTED]:
Le 5 déc. 08 à 16:00, Påhl Melin a écrit :
2008/12/5 Benjamin Stiglitz [EMAIL PROTECTED]:
I need to use timers in a low level library where I need to specify
asynchronous callbacks to a timer function. I will not have any run
loop so I cannot
2008/12/5 Joseph Kelly [EMAIL PROTECTED]:
From everything you've said, Påhl, you can very easily implement it using a
combination of Cocoa and Core Foundation. I posted a response yesterday
which you might want to look at.
Thanks Joseph. I looked at your source more closely and I think I get
2008/12/5 Sherm Pendley [EMAIL PROTECTED]:
On Dec 5, 2008, at 7:52 AM, Påhl Melin wrote:
...to have the TimerFunction() function be called twice per second
after 5 seconds (time in millisecond). Nothing else – you don't need
to idle your thread at all. Dotnet handles everything by itself.
2008/12/5 Sherm Pendley [EMAIL PROTECTED]:
On Dec 5, 2008, at 3:16 PM, Påhl Melin wrote:
2008/12/5 Sherm Pendley [EMAIL PROTECTED]:
You'd have far, far less trouble programming for the Mac if you'd simply
learn how Cocoa works, instead of trying to reinvent .NET in Objective-C.
When in
On Dec 5, 2008, at 3:22 PM, Påhl Melin wrote:
I didn't really decide I shouldn't use a run loop for the timers. I am
porting a library from another platform and just wanted a quick answer
if I could get a similar timer API behavior in either Cocoa, Core
Foundation or BSD Unix (with a
I need to use timers in a low level library where I need to specify
asynchronous callbacks to a timer function. I will not have any run
loop so I cannot use NSTimer. Are there any low level timer API to use
instead? I haven't found anything useful (yet) on google nor ADC. I
assume there must exist
NSRunLoop use to be based on the function select() (it was in GnuStep
anyway), it waits for inputs but also has a single timeout value also,
NSRunLoop works out how long the timeout value should be for the
shortest NSTimer. If you want to wait on multiple timers without using
run NSRunLoop
Yes, I could set up a new thread, handling a list of usleep()
intervals between the actual timer events but it would be very hard to
make a reliable, drift-free timer service, handling lots of timer
events and it would take quite some time to develop a fully functional
and reliable version. I
Le 4 déc. 08 à 14:00, Påhl Melin a écrit :
Yes, I could set up a new thread, handling a list of usleep()
intervals between the actual timer events but it would be very hard to
make a reliable, drift-free timer service, handling lots of timer
events and it would take quite some time to develop
Le 4 déc. 08 à 15:17, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
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
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
Le 4 déc. 08 à 15:17, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
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
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.
You might find if you
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
Le 4 déc. 08 à 15:50, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
Le 4 déc. 08 à 15:17, Påhl Melin a écrit :
2008/12/4 Jean-Daniel Dupas [EMAIL PROTECTED]:
If you want to avoid Cocoa, Cocoa-dev is probably not the best
mailing
list
to ask.
You will have more
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
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
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
On Dec 4, 2008, at 7:14 AM, Påhl Melin wrote:
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
On Thu, Dec 4, 2008 at 8:00 AM, Påhl Melin [EMAIL PROTECTED] wrote:
Yes, I could set up a new thread, handling a list of usleep()
intervals between the actual timer events but it would be very hard to
make a reliable, drift-free timer service, handling lots of timer
events and it would take
28 matches
Mail list logo
