By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,491 Members | 1,207 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,491 IT Pros & Developers. It's quick & easy.

atomic cross-window IPC?

P: n/a
Short: One window writes to <input>, the other reads the same <input>.
Is it a race condition or are the reads/writes atomic?

Long: My app has an option to print results in a nicely formatted,
print-friendly way. The main window is loaded with options, textboxes,
buttons, has some graphics etc, nice as an app but not really
printable, so clicking "print" icon opens a new window with the page
with a nicely formatted, print-friendly summary, some comment entry
textareas and tools for printing (whatever unnecessary on printout,
hidden through @media print{} stylesheets.) The app window, on any
value change fills in a hidden input field. The print window
periodically (every 2s) loads the input field and introduces changes to
itself if necessary. My code sniplets below. The question is: Am I too
paranoid, or will it -just work- or it won't work despite me being
paranoid? Other comments? Any way to do it better? For now the code
works, but you never know what bugs lurk in the IPC.

--app window--
function update() // called on any change to any value in the form
when the user types.
{
....
document.f.comm.value=val1+"!"+val2+"!"+fieldx+"!" .... etc.
}

--print window--
var datastring='';
var dataarr= new Array();

function initdoc() // called from <body onload="">
{
....
setInterval(pickdata,2000);
}

function pickdata()
{
if(datastring==opener.document.f.comm.value) return; // data
unchanged, no need to update

do {

datastring=opener.document.f.comm.value;

// if changed since previous read, likely broken, reread. Paranoia?
} while(datastring==opener.document.f.comm.value);

dataarr=String(datastring).split('!');
....

}

Dec 22 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
bw****@gmail.com said the following on 12/22/2005 5:01 AM:
Short: One window writes to <input>, the other reads the same <input>.
Is it a race condition or are the reads/writes atomic?


Its a race condition.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 22 '05 #2

P: n/a
> The question is: Am I too > paranoid, or will it -just work- or it won't work despite me
being paranoid? Other comments? Any way to do it better?
I think you're just beeing paranoic, but it's really possible to occur
an error
document.f.comm.value=val1+"!"+val2+"!"+fieldx+"!" .... etc.
I preffer this way:

document.f.comm.value = [val1, val2, fieldx].join("!");

Anyway, the first one is faster :)
function initdoc() // called from <body onload="">
You shouldn't use onload since it depends on images loading...

Try to add this on the end of your html, like bellow:

<script type="text/javascript">
trigger();
</script>
</body>
</html>
do datastring = opener.document.f.comm.value;
while(datastring == opener.document.f.comm.value);


This paranoia will lead you to an endless loop... If the content
doesn't get changed =/

Dispite of the things that I would change, I think you should change
your solution... You could call the popup's "pickdata" on your "update"
function...

Something like:

if(!popup || popup.closed)
popup = open("uri", "an unique name would be good here", "params");
//it's good to check if the function exists since the user can go to
another url or the page may be just loading yet...
popup.pickdata && popup.pickdata();

Well, good luck :D
--
"Invente, Tente!!! Faça um código eficiente" (eu)

Jonas Raoni Soares Silva
---------------------------
jonasraoni at gmail dot com
http://www.jsfromhell.com

Dec 22 '05 #3

P: n/a
> document.f.comm.value = [val1, val2, fieldx].join("!");

True, prettier. Speed is really of no concern here.
You shouldn't use onload since it depends on images loading... a single small gif with printer icon... may it fail somehow? (user
turns images off or something).
while(datastring == opener.document.f.comm.value);
of course I screwed up typing instead of pasting. That's != obviously.
Rereading the string so if it changed between the first and second
read, it's likely broken. But if the time slice the window gets is long
enough, the same broken string will be read twice so that would be
useless. Some kind of semaphore/"taint bit" would come in handy. The
problem is I can't block writing, because it is called onChange, so I
don't know how long till it will be called again, and the changes won't
make it to the print form until then. The corrupted readout isn't that
much of a problem, because it will fix itself in 2s anyway, but I'd
like to learn how it is done -right- and not just "satisfactory well".
popup.pickdata && popup.pickdata();


Thanks, I think I'll go this way (maybe even passing data directly,
popup.pickdata(data); - just couldn't find any cross-window scripting
example/manual that shows anything else than reading forms of the other
window, nor to figure out descendants of what object are the top-level
functions. Seems the simplest is true and all tries like
popup.document.pickdata(), popup.window.pickdata(),
popup.getElementById('readscript').pickdata() were just
over-complicating the problem.).

Nevertheless I'd still love to learn how to transfer the data
asynchronously, just for educational purpose.

Thanks for a helpful answer.

Dec 22 '05 #4

P: n/a
Jonas Raoni said the following on 12/22/2005 10:32 AM:

function initdoc() // called from <body onload="">

You shouldn't use onload since it depends on images loading...

Try to add this on the end of your html, like bellow:

<script type="text/javascript">
trigger();
</script>
</body>
</html>


In that scenario, the onload is preferable. The onload will ensure the
document has loaded. Adding a script call at the end of the body won't
ensure it is loaded.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 22 '05 #5

P: n/a
On 2005-12-22, bw****@gmail.com <bw****@gmail.com> wrote:
Short: One window writes to <input>, the other reads the same <input>.
Is it a race condition or are the reads/writes atomic?


I have been led to believe that all javascript processes are atomic.
OTOH some claim that separate documents opperate synchronously, I have never
noticed this.
--

Bye.
Jasen
Dec 23 '05 #6

P: n/a
Jasen Betts said the following on 12/23/2005 12:58 AM:
On 2005-12-22, bw****@gmail.com <bw****@gmail.com> wrote:
Short: One window writes to <input>, the other reads the same <input>.
Is it a race condition or are the reads/writes atomic?

I have been led to believe that all javascript processes are atomic.


You were led to believe incorrectly when it comes to two windows.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 24 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.