| Subject: | event queue shenanigans in JavaScript |
|---|---|
| Date: | Tue, 06 Nov 2001 21:01:16 -0800 |
| From: | Daniel Matejka <[EMAIL PROTECTED]> |
| To: | [EMAIL PROTECTED] |
| CC: | [EMAIL PROTECTED], [EMAIL PROTECTED] |
Hey guys -- Mitesh tells me I should ask Brendan about this; Brendan thought I should cc: the rest of you folks, too.
I'm coming into this a little late, so I may not have my story quite right. It apparently springs from bug 89137 (Move netscape.cfg and autoconfig) , itself an evil stepchild of bug 75955 (Implement a mechanism for getLDAPAttributes) . That's what Mitesh tells me, anyway.
I believe he had this working on some branch. I think the fix was called from JS somewhere but coded in C++; some special-use callback function which apparently stuck out like a bowling ball in a hen house and you guys(?) objected to the new method.
So at your(?) prodding Mitesh is trying to rework the fix for the trunk in pure JS, dealing only in extant interfaces. I'd like to argue that whatever the ugliness of the special-use function, this new approach has to be worse.
You should see the things he's doing in script. Accessing nsIEventQueueService, and pushing and popping new event queues. And running little event loops. I think whoever accidentally failed to make those methods unscriptable should immediately go drink ten tasty margaritas and say a few hail Marys. Is this something we want to do in script? It just feels terribly out of place; this should be in assembly or something.
Is it not dangerous and weird? Isn't event queue code something across the looking glass from JS? The problem Mitesh is having right now goes like this. His code is inserted into the foggy application startup sequence somewhere between ground zero and the creation of the first NSPR event queue on the UI thread. He needs a stack of event queues to do his deeds because he's firing off asynch IO on top of other similar asynch IO; exactly the reason one needs an event queue stack.
This kind of thing coded in JS means that the event queue itself is an object referenced by the JS engine. It's important that the queue be shut down and destroy itself before the normal application initialization code kicks in, because that code latches onto the current UI event queue and blesses it for the lifetime of the app. It is quite surprised to discover a stack of event queues already in place and fumbles the ball. Mitesh tells me it looks like the pushed event queue isn't being destroyed quickly enough because the JS engine itself is holding a reference to it. Sounds kind of reasonable.
I reiterate my eeyewww about coding something like this in JS. Accepting that Mitesh' Task needs to be done, what could be so awful about a special-purpose callback just for him so he can execute in C++, where it's been demonstrated on the branch that this dangerous process can be made to work, that it outgrosses tweaking the event queue manager in script? Inquiring minds...
