atomic cross-window IPC?

B

bwucke

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('!');
....

}
 
R

Randy Webb

(e-mail address removed) 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.
 
J

Jonas Raoni

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>
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
 
B

bwucke

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.
 
R

Randy Webb

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

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.
 
R

Randy Webb

Jasen Betts said the following on 12/23/2005 12:58 AM:
I have been led to believe that all javascript processes are atomic.

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,763
Messages
2,569,562
Members
45,038
Latest member
OrderProperKetocapsules

Latest Threads

Top