Multithreadedness and DOM-node madness

2005-10-18 21:53:00

Spent most of the day today wrestling with implementation details for Scooby. It was an interesting day in that my co-worker Bobby learned some stuff about JavaScript, and I learned some stuff about good appliation design.

The first issue we sort of ran aground on was the weird 'multithreadedness' of JavaScript execution. My first experience with this was the occaision of my learning the work 'deterministic.'

I had some code where some stuff that happened in a sub-function was clearly finishing long after statements in the main code that were much futher down on the page. A co-worker of mine, a database guy told me that that was not possible -- that programming languages have to be 'deterministic.' When I sat him down and showed it to him, he grumbled and pronounced it a bug in the JavaScript implementation.

Bug or not, it seems that the JavaScript interpreter hands off execution of the sub-function to another thread, and blythely continues executing the main sequence of code with the assumption that everything works hunky-dory in the sub-function, and seemingly with no concern for the timing of it.

I don't know if this is some kind of optimization to speed execution, or what, but it sure can bite you in the ass, since it is totally 'non-deterministic,' and seems not to be what most programmers expect. It only takes a moment to come up with the simple workaround of writing your code in the main thread to wait for a return value from the sub-function, of course, but that does feel kind of ad-hoc and crappy.

If anybody has any clue as to why this happens, I'd love to hear more -- the rationale for that design decision, or whatever technical details I'm capable of understanding.

The other irritation was caused by the way I designed some of the classes for the Scooby app -- I'd allowed some of the controller code to creep into my model (the main calender event data class), and the end result was that it completely borked the calls to the new ScoobyService methods Bobby wrote for saving calendar events.

The root of the issue turned out to be a reference to a DOM node in the data class. Ah, yes -- good ol' DOM-node references wreaking havok again. I'm still trying to figure out exactly what was going on there, but the end result was that JSON-RPC was trying to serialize something that looked like the entire DOM tree for the Scooby calendar app. When you examined the JSON object in the log, you could see huge swaths of table markup, and even form elements showing up in there.

The only thing we could figure was that DOM nodes have references to their parents, or to the main document. That's the only explanation for how all that stuff ended up in our object, because the object property was literally a single div element.

Obviously the solution is to keep the data partitioned off from the rest of the app. Interesting to see that sometimes there actually are practical benefits to a more rigorous adherence to the MVC paradigm, instead of just that warm feeling inside that your code is 'properly' done.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.