semaphore using GM_*value?
Kodak
same time so I need a semaphore. Is there a way to do a safe check and
change value in GM? (should such function use ipcILockService
interface?)
Anthony Lieuallen
> Hi all, I need to synch couple of tabs not to do same thing at the
> same time so I need a semaphore. Is there a way to do a safe check and
> change value in GM?
Javascript in Firefox is single-threaded, so you don't need to worry
about other scripts running, unless you specifically stop execution and
continue later (via an ajax call, a setTimeout, event handler, etc).
So, if you I.E. get a value (let's say a lock) that is false,
immediately set it true and _then_ start doing your work (which can
include the "stopping" methods mentioned above), no other script is
going to execute between your get and set.
Kodak
synchronize couple of windows access to GM persistent properties
(preferences) being set using GM_setValue - would you agree that then
multiple simultaneous access to preferences can happen in the same
time then? Access to single GM functions like GM_getValue/GM_setValue
is probably serialized by firefox (is it?) but then I need to have a
function that gets and sets value in atomic transaction.
The best would be atomic function, something like
function GM_setValueIf(value, default, checkEqual)
which would set value only if current one equals checkEqual
Anthony Lieuallen
> If Javascript is single-threaded then it is per window.
Do you have any evidence to back up this statement? I do not believe it
to be true.
Kodak
dozens of windows opened all javascript in them is run in single
thread? So any long lasting call, make it a not asynchronious ajax
call would stop all of your pages from loading/interpreting
javascript? I'm not feeling it is.
Well it can be a single thread with some time divisioning between
"windows" but then still I would need a mechanism to sychronize
"windows" somehow so we are comming to the start.
cc
> On 8 Lis, 22:23, Anthony Lieuallen<arant...@gmail.com> wrote:
>
>> On 11/8/2009 1:31 PM, Kodak wrote:
>>
>>> If Javascript is single-threaded then it is per window.
>>>
>> Do you have any evidence to back up this statement? I do not believe it
>> to be true.
>>
> I do not have it - I will need to dig it. Are you saying that having
> dozens of windows opened all javascript in them is run in single
> thread? So any long lasting call, make it a not asynchronious ajax
> call would stop all of your pages from loading/interpreting
> javascript? I'm not feeling it is.
>
probably have said if he hadn't. IIUC, that's actually one of the major
performance roadblocks for Firefox in the next year or three: Javascript
in Firefox (and in nearly every other browser, except of course Chrome)
is single-threaded, because multi-threading would break lots of scripts.
Namely, all the scripts that assume what is essentially cooperative
multi-tasking (like Anthony's suggestion). Electrolysis and other
projects may help considerably here, but backward compatibility is a
tricky thing.
> Well it can be a single thread with some time divisioning between
> "windows" but then still I would need a mechanism to sychronize
> "windows" somehow so we are comming to the start.
>
Kodak
saying that two lines of code should not be divided in time/between
pages - is browser queing all function calls/event routines?
Anthony Lieuallen
> .. 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.
Kodak
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.
Vectorspace
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?