RFE: Run plugins in a seperate thread(s; one per plugin) to decouple them from other activities in the browser. Currently a very busy Flash plugin (like a fast endless animation) can make all other tasks in the browser/mail/news/calendar very sluggish. Moving the plugin into a seperate thread (and for X11 platforms: A seperate Xserver connection opened with XOpenDisplay()) would greatly improve that situation (a good example for the performance improvements is "Konqueror" which runs plugins in a seperate process - in most cases this design outperforms Mozilla by magnitudes (just test it yourself via running multiple Flash animations from http://www.happytreefriends.com/ in parallel)).

Really should be a carefully sanitized separate process for security. There's no reason to assume plugins are benign.

Running NS4.x-style plugins in a seperate process may be possible, but running plugins which use the new XPCOM-based Mozilla API in a seperate process would be a horrible pain since _EVERYTHING_ the plugin accesses would have to be transferred between the two processes (I am not even sure whether the new plugin API actually allows this... please anyone correct me if I am wrong...).

closely related to bug 156493

Roland, concerning your Whiteboard entry: 1) there already is a bug about separate processes, so I see no point in asking people to file another one. 2) when I said "related", I meant it (not dup, or I had said it). I don't know how close the relationship is, though, but I guess there is one...

*** Bug 269679 has been marked as a duplicate of this bug. ***

Seems like an excellent use of threads if technically feasible.

Are our XPCOM services, by defintion, thread-safe?

*** Bug 240852 has been marked as a duplicate of this bug. ***

(In reply to comment #7) on average they are not and most be accessed using a proxy.

erm, must :(

Better to go for a separate process and get better protection; a thread might sole responsiveness, but would not solve other problems like crashes. That's bug 156493