Best way to implement timers

[Phil Endecott]

Dear experts,

I'm considering the best way to implement timers in my native OpenGL
app. Basically I need to arrange for a callback at some point in the
future e.g.

....
schedule_timer(10,&timer_expired);
....

void timer_expired() {
... change state ....
... request render ....
}

At some point I will start to use the new native event loop code, so I
checked the docs for that and I don't see any explicit support for
timers; it seems to use file descriptors (presumably with a select()
call); is there some way to make an fd become readable after a delay,
or something?

But that's still in the future; for now I'm using the Java event
loop. So is there some Java function I can call to schedule a timer,
and if so can I do that without needing a separate Java stub for each
place that I use it?

The alternative is that I write my own timer using a dedicated
thread. This probably isn't too hard but feels like re-inventing the
wheel, and it will probably have bugs when summer time starts or
ends! There are also thread safety issues - I'd prefer to at least
have the option of having the timer callbacks on the same thread as
input events.

How have others dealt with this?


Thanks, Phil.

[David Turner]

timer_create() ?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Phil Endecott]

On Dec 18, 4:46 pm, David Turner <di...@android.com> wrote:
> timer_create() ?

Well the main issue with that is that the callbacks are in signal
handlers, or in new threads for every callback. The former is hard to
work with (you can't even protect shared state with a pthread_mutex)
and the latter is slow.

[Igor R]

>> timer_create() ?
>
> Well the main issue with that is that the callbacks are in signal
> handlers, or in new threads for every callback.  The former is hard to
> work with (you can't even protect shared state with a pthread_mutex)
> and the latter is slow.

You can use asio::deadline_timer
http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/tutorial/tuttimer2.html

[David Turner]

Then hack your event loop implementation to implement timers if it doesn't provide them. There really isn't any other way if you only want to use a single thread.

[Phil Endecott]

On Dec 18, 5:46 pm, David Turner <di...@android.com> wrote:
> Then hack your event loop implementation to implement timers if it doesn't
> provide them. There really isn't any other way if you only want to use a
> single thread.

It's not *my* event loop implementation, it's whatever is going on
inside the Java runtime, and I'm not sure how I can hack that. Does
anyone know how this would be done in Java? I've looked at the docs
but I can't find anything, probably because I don't know enough to
search for the right things.

I'm currently hacking together something with a thread and a queue of
pending timer expirations and condition variable. It's one of those
things that takes half an hour to implement, and then a couple of days
to think of all the corner cases....


Phil.

[Phil Endecott]

On Dec 18, 5:22 pm, Igor R <boost.li...@gmail.com> wrote:
> You can use asio::deadline_timer

Yes, thanks for the pointer; Boost.asio is something that has never
yet got to the top of my list of things to learn about. Does it
"plumb in" well with the rest of the Android infrastructure?

[Igor R]

> Yes, thanks for the pointer; Boost.asio is something that has never
> yet got to the top of my list of things to learn about.  Does it
> "plumb in" well with the rest of the Android infrastructure?

Well, I'm not an Android expert, but IMHO the main advantage of the
NDK is that it allows us to use virtually any portable c++ library. So
why to reinvent the wheel?
Personally I ported to Android my project that uses Asio (and a lot of
other Boost libs) massively, with minimal effort -- and haven't
encountered any problems so far.

[Dianne Hackborn]

If you are looking for information related to the Java language APIs, you would get better help from a group that discussed those -- android-developers or StackOverflow for example.

That said, Handler has methods to post runnables and send messages that will be processed at a certain time or after a certain delay.  That is a common way to do timers in the framework.

See here: http://developer.android.com/reference/android/os/Handler.html

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Phil Endecott]

On Dec 18, 10:51 pm, Dianne Hackborn <hack...@android.com> wrote:
> That said, Handler has methods to post runnables and send messages that will
> be processed at a certain time or after a certain delay. That is a common
> way to do timers in the framework.

Thanks Dianne. So, is that something that is common to the new native-
only event loop API stuff, or is that completely different? I've
downloaded the new NDK to get the docs and it doesn't seem to say
much, and the APIs I did find didn't look much like this "Handler"
thing. (I'm just trying to understand which options are future-proof
and which are not.)

[Dianne Hackborn]

Handler is purely a Java thing.  The native APIs are lower-level and intended mostly for you to write your own event loop in a separate thread.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.