On Fri, Jun 11, 2010 at 9:43 AM, Vitali Lovich <vlov...@gmail.com> wrote:
> I think I'm failing to see what you are trying to accomplish & why you are
> trying to add threads to the mix here?
i'm trying to REMOVE threads from the mix. My current setTimeout() impl
starts a thread for each timer. When the timeout is reached, a Locker is
used to lock v8 and the timeout handler is run. Since the timeout can run
arbitrary code, which might somewhere use an Unlocker, the behaviour is
slightly different from a browser's impl.
What i'd LIKE to do is get a C signal (via timer_create()) every N ms, check
if any setTimeout() timers are pending, and run them from the main thread
(where the C signal is delivered). That way i'm ensured that my setTimeout()
impl behaves more like a browser impl. For 95% of cases, the threaded impl
will behave like a browser-side impl because a Locker is put in place just
before the timeout func is run, but as soon as the timeout func calls code
which calls code which calls code which uses an Unlocker, it behaves
differently.
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
> }
>
That is informative, but i can't use this approach unless i literally wrap
my whole application in that loop. However, i'm writing a library, and not
an application, so i cannot enforce that users actually do this.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
