I think I'm failing to see what you are trying to accomplish & why you are
trying to add threads to the mix here?
The way that the glib event loop works is as follows:
while(run application) {
select(fds, time remaining until next time-based event)
if the fds have activity { respond to fds as appropriate; }
else if the timeout hit { process the timeout event, remove the timeout
from the stack }
peek at the timeout stack & recompute time remaining until next event
}
On Fri, Jun 11, 2010 at 12:02 AM, Stephan Beal <sgb...@googlemail.com>wrote:
> On Fri, Jun 11, 2010 at 5:01 AM, Vitali <vlov...@gmail.com> wrote:
>
>> A typical solution for event loops is to use select with the timeout
>> for the next scheduled function. The scheduled function is set up in
>> the v8 code prior to returning to the select, so you'll always know
>> what the next sleep time should be.
>>
>
> My plan was to use a central timer that ticks fairly often (somewhere
> between 25-100ms), and checks for/executes setTimeout() callbacks. i'd like
> to avoid creating an arbitrary number of timers (or threads, as the is
> currently the case).
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
>
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
