Comment 82 for bug 226470

(In reply to comment #81)
> Why do you think there are multiple threads involved? There should only be
> one.
>

I've got a debug compiled Firefox currently running under gdb with several dozen open windows (and perhaps a hundred+ tabs). If I ctrl-C it and say "thread apply all bt" I get 7 active threads (1, 2, 3, 12, 25, 26, 27). Now gdb cannot give me meaningfuls stack traces for the later threads, but I view this as a gdb bug in tracing system calls. #1 is, as you have said, the "main" thread apparently controlling much of the activity with gtk/gdk/glib. #2 is apparently the single network communication thread, which is of course highly questionable if my system (or network) happens to have separate connections for dial-up, DSL, Cable, Satellite and WiFi links to various sources. Single-threading network communications at the application level is wrong. The distribution and collection of network requests is under OS level mamagement problem. If thread creation is not prohibitively expensive (and it will not be on 2, 4 & 8 core processors) then all network requests should be running on individual threads. I do not fully understand what threads are created and destroyed within the current Mozilla/Firefox model -- if there is a document which clearly outlines this I would be happy to review it. (I strongly suspect that the "model" for the program is lost within the minds of a few developers who wrote core aspects of the code -- presumably many of whom were writing for a Windows paradigm rather than an open source Linux paradigm.)

I have no evidence that asynchronous operations, e.g. the HTML REFRESH operation or asynchronous javascript timers are or are not operating in different threads (the handling of asynchronous operations isn't exactly documented to the best of my knowledge). It really doesn't matter. If an async interrupt occurs in the "default" main thread it can still add operations to the glib "event" processing queue unless it recognizes that it is adding such operations to a window (or its subcomponents) which are in the process of being deleted.

I am willing to be wrong about this. Point out the precise functions where REFRESH and/or Javascript Timeouts are being handled and point out the precise locations where they will lock or block on access to the window in which they are running. Or point out that all of these window activities are being bounced back up to the top level where they are being enqueued and the enqueing will detect an attempt to enqueue on a "Destroyed" object. Because as things stand right now -- it looks like the code is destroying the window and it is enqueing things to be done to the window which has been destroyed. One should not perform magic upon an object incapable of supporting magic. At least in my humble opinion.