Now with asynchronous GM.getValue and GM.setValue this should have changed a bit. Is it still guaranteed that a construct like GM.setValue(name, await GM.getValue(name)) will not revert any changes made by other invocations of GM.setValue?
On Tuesday, 10 November 2009 at 20:59:19 UTC+1 Vectorspace wrote: > There is a project underway to to enable Firefox to use separate > processes for UI, content, and plugins: > https://wiki.mozilla.org/Content_Processes > If there are separate processes for each tab, that might result in > JavaScript being multi-threaded between tabs? > > Kodak wrote: > > Thank you very much for time spent on this. I think it clearly shown > > you were right. > > I will take for granted that browser is queing function calls/event > > routines so such single piece of code should be (for now, in current > > firefox at least) atomic. > > Thanks again. > > > > On 10 Lis, 15:30, Anthony Lieuallen <[email protected]> wrote: > > > >> On 11/10/09 06:03, Kodak wrote: > >> > >> > >>> .. is browser queing all function calls/event routines? > >>> > >> Yes. Try this: > >> > >> http://arantius.info/looper.html > >> > >> Open one window with one tab, with this page. Click 'start' and you'll > >> see that > >> > >> A) Your CPU (or one of its cores) pegs to 100% utilization. > >> B) The entire browser becomes very unresponsive. > >> > >> The browser is unresponsive because it's written in XUL+JS, and its JS > >> can't execute while JS in the page is executing -- there's only one > >> global thread. > >> > >> You should note that the time between "end" (of one loop) and "start" > >> (of the next) that it reports is very small, probably well under 10ms. > >> If you can, refresh the page so it isn't running anymore (or force kill > >> and restart the browser). Open a second window with this page. Click > >> start in one, see the very small delays. Click start in the other, and > >> you'll see the delay between loops jumps to at least 1 second, in my > >> case around 1.2 seconds. The JS in one window has to wait for the JS in > >> the other window to loop, before it gets to execute again. > >> > >> Or, to repeat myself, with proof this time: > >> > >> Javascript in Firefox is single threaded. Across all tabs, windows, > >> etc. You have to start an entire separate instance of Firefox (and that > >> must be on a separate profile because of how Firefox works) to get > >> another concurrent thread. > >> > >> P.S. Web worker threads [1] are an exception to this. You'll note the > >> restrictive API they get, however. That's how they work. JS is single > >> threaded in Firefox, basically because there's so much legacy JS that is > >> not single threaded. > >> > >> P.P.S. You might also note that Chrome does not exhibit this particular > >> behavior. Each of Chrome's tabs/windows execute in a separate OS-level > >> process, and do not block each other for execution. I'm not sure how it > >> handles the potential problem of cross-window access. > >> > > > > > > > > -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/greasemonkey-users/30c0089c-6de8-49a6-8984-ae07ac898784n%40googlegroups.com.
