Contents
This page is in group Technology.
Intro
My starting point with this note was my surprise of the JavaScript «concurrency model» [01] – as described in HTLM5 [02] («WebAppAPIs»). I asked myself whether this «single-threaded» model had been influenced by the Model-View-Controller (MVC) [03]. Maybe, in any case it is the Document Object Model (DOM) [04] that rules inside WepAppAPIs.
Single-threaded and concurrent! Is it possible?
I also wanted to understand why there seems to be so little language-based concurrency available for web coders. Something between DOM and Chrome OS [07].
I hoped for some help with this, so I posted a theme at golang-nuts [08]. I got some!
Disclaimer: I have had to read myself up on this! If you find any errors and think it worthwhile, I’d like to have them corrected. Sometimes I feel like I’m on thin ice.
MVC (Model-View-Controller) :-:
In [05] (with comments) there’s a discussion on which of these represent MVC best:
|
|
I don’t really care. I grasp the idea anyhow: separation of concerns. The main idea of complexity handling. It’s interesting that the browser takes role as either Controller or View in the two examples. The right suites my experience, since I am not a web programmer. The Wikipedia article also shows a user, so I have included myself in the table above.
MVC was originally made for Smalltalk, with Objects. There’s no concurrency in the traditional sense here. But I spot more concurrency in the right than in the left example. So maybe there’s still some of it?
I am kind of proud that MVC was invented by a Norwegian, Trygve Reenskaug. He created «the Model-View-Controller pattern as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives», from his home page at UiO. I have had communication with him, see Letter with Reenskaug below.
Aside: About Objects and Processes in Smalltalk. From [10] (starting off with a small minute by me of the Simula-67 25 year’s anniversary in Oslo in June 1992) we read that:
On the same occasion Bjarne Stroustrup told me (after I had approached him for an autograph (blush)) that «Process» had been inserted into Smalltalk after Kay and Tesler had finished their work on it. He was not sure whether the «process term» was suitable enough. «Now they must have semaphores» he said. To handle concurrency Process, ProcessScheduler, Semaphore, SharedQueue, critical sections, Delay and Promise (the latter for background tasks) were included in Smalltalk. Interesting, but different from more «mature» CSP-based languages like occam and Go. |
DOM (Document Object Model)
DOM Level 3 supports keyboard and event handling, according to Wikipedia. HTML code is parsed «into a DOM».
According to [06] we read that
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
A coder relates to DOM trees. From Wikipedia I read that «the nodes of every document are organized in a tree structure, called the DOM tree, with topmost node named ‘Document object'».
In the W3C DOM document [06] there is a DOM Activity statement. I am a latecomer since DOM was a W3C working group during 1997-2007. It defined how web software should create and relate to a web page. Other working groups followed up.
This is where [02] comes in; and it’s from August 2013 (this year).
Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:
..script, JavaScript, Event handlers like DOM type or (a list) or «otherwise«. «Processing of technologies like XBL or SVG that have their own scripting features.»
The last point perhaps explains a comment at my golang-nuts question [08] about a system made for Erlang:
But it reminds me of an interesting experiment by Joe Armstrong in Erlang: A small javascript snippet on the client side exposes a canvas to the Erlang server through a websocket. Now the Erlang *server* sends drawing commands to the client. In a sense, the client is just a terminal able to draw vector graphics. All the logic happens on the server side of things. (Jesper Louis Andersen, 2013)
The document then defines the «processing model»: «This specification describes three kinds of JavaScript global environments: the document environment, the dedicated worker environment, and the shared worker environment.»
Then the document describes «A script execution environment» and that «The characteristics of the script execution environment depend on the language, and are not defined by this specification.»
And then «In JavaScript, the script execution environment consists of the interpreter, the stack of execution contexts, the global code and function code and the Function objects resulting, and so forth.»
A postulate
So W3C does not seem to tie everything to JavaScript or to a particular «process model», even if I do have the impression that they do so with their «document model». But from the list of compilers which compile to JavaScript source code (JavaScript @ Wikipedia), it looks like JavaScript now has the role that C once had. I believe the first C++ compiler generated C. After the transputer was dead we used the Southampton Portable occam Compiler (SPoC) that also generated C; it ran with a scheduler. We have later used tools like System Architect which generates C (or C++.) But then, some choose to code in C (or C++); personally I have for many years (not chosen!). As always, when the priests have learnt the scripture it introduces a conservative mind-set towards other languages.
I assume that compiling to JavaScript is easiest since the browser already has the JavaScript runtime – than to compile to some other «script environment».
But there seems to be hope for alternatives to the event-loop model.
Postulate: Event-type concurrency is a «goto» of concurrency
Either you are now angry with me because you’re using the event-loop and callbacks and think it’s great. I have used several of my latest blog notes trying to understand you. And I think I do. There is no disrespect to the event-loop in the above statement. (But after I wrote this note I have rediscovered a paper by Peter H. Welch about the dangers of callbacks in OO [12])
I once heard the same being said about the channels of occam – and now Go. I loved these channels and couldn’t understand why this was said, even at a conference. Only years after I understood that it’s (probably, I still struggle a little) true. A channel may certainly be used different ways.
Just from my non-academic desk there’s the knock-come deadlock free pattern that used correctly causes synchronous data flow to be yes, deadlock free. There’s the XCHAN channel type that makes both asynchronous and synchronous non-blocking communication also deadlock free. And there’s feathering that enables a system using XCHANs to avoid sending something that a receiver implicitly is not interested in; an implicit subscribe and unsubscribe mechanism (see PUBLICATIONS menu above for all of these, or the right column here. XCHANs have been proven to work, see here). And then there are other patterns and transaction types. Altogether this probably makes the channel the goto of process-to-process communication. (Read about the history of pipes, here)
So..
I think it’s correct to make the above statement about event-loop concurrency. However, I did write a goto of concurrency, as one of several. But on the web I have a feeling it pretty much is the goto of concurrency. The mantra is that it’s «single threaded».
But the process model of this particular threadless design is rather weak: if you plan to do any concurrent activity you have to make a state machine to be able to join back to the place you were before you did the last matter. The application in some way becomes its own scheduler! I have experienced this because the same thing can happen if you chose the wrong methodology to build on top of, even synchronous channels, see here.
A scheduler running on one core only sees functions, and it sees itself as single threaded, just like the web coding discussed here. It’s the paradigm or language on top of this that would know about threads or processes. So in the final end any scheduler has an «event-loop», the point where it has not decided yet which process to schedule (in occam, if it has nothing to do and no registered future reason to live for (timeout or some interrupt) it’s a STOP (deadlock). In Promela it’s SKIP (ok). In Go I think it’s a STOP (deadlock)). So there are languages on top of this, that make the scheduler hidden. It’s the very visible type of event-loop scheduler I discuss here.
When I postulate as above I mostly look at the scheduling side of things. But I also mention communication and synchronization; this is part of how a shared resource may be handled. Communicate it (channels), wrap all access into a process or place some mutex around it. These mechanisms will introduce different functions in the called-back function. In my world the called-back function is one for each process (reschedule or callback to the next line after a synchronization point); communication is with a channel library that may block if it’s first on a channel (just s single return to the scheduler).
But in the «WebAppAPIs» [02], even if they have defined a «storage mutex», it basically has so primitive a process model that blocking is not allowed. They think it’s single threaded, but it might not be. Most web programming seems to be coded with this model, in 2013. I wrote a run-time scheduler for a microcontroller in 1988. In many ways it reminds me of today’s JavaScript model. But it had mailboxes. See [09].
But is it needed?
They say it’s single-threaded; but they might still get concurrency. They say that concurrency is not needed, things look simultaneous anyway; I say that’s concurrency for you.
But the WebAppAPIs, DOM and MVC all are still rather single threaded. At least the two latter are based on objects. These objects do their jobs fast enough to provide the concurrency they need in their single-threaded world.
Maybe it’s unfair to say that the event-loop process model is weak? Since there is no process model it can’t be weak?
When Objects have done their job as cognitive carriers of abstraction, the next step is to think about parallelism. On one machine that’s concurrency (Go, occam); on several cores with shared memory it’s still concurrency (Go, occam); but make both memory and core local, that’s parallelism (occam or anything plus MPI etc.).
To do this a solid process model is needed.
To conclude: Yes, I do think the so-called single-threaded universe of HTML5 and web application implicitly have some of their roots from MFC. And I now know that it explicitly is held up by DOM.
(Comments are welcomed!)
Letter with Reenskaug
I have had communication with Trygve Reenskaug, the inventor of the MVC model. He commented on this blog note (from Norwegian, approved by Reenskaug):
- The left column of the MVC table with its implementation details is at a completely wrong level. The right column is more suitable since it better matches the user’s mental model.
- Based on your description, DOM seems to be at a level below MVC. In MVC the Model is the business part and represents user information. The purpose of MVC is to bridge the gap between the data model and the user’s mental model. The user’s mental model includes both an information model and an action model, database and operations. It will be best match when the mental model is included in the program’s Model. A View is only a transducer between the user’s senses and the Model in the program, while the Controller sets up and synchronizes Views.
- A person’s mental model is probably multithreaded, although this is rarely conscious. I’ve never seen the need to create the MVC explicitly as multithreaded. Should I ever need it, it might be in the Model section, or rather in the underlying infrastructure. For MVC the Model appears as one object, its internal structure is undefined.
- I have stayed far away from multi-process because the topic seems full of pitfalls. I have seen that I will have to take the subject seriously, but then in relation to DCI. Your work is very interesting to me and I’ll pick it up when I get to the point where I can concentrate on multi-process.
Trygve
—
DCI is «Data, Context and Interaction» [11], a «complementary to MVC» – a new concept also invented by Reenskaug. It looks extremely interesting and relevant. Also the fact that Trygve states that multi-process is interesting in the DCI context – when the Wikipedia article does not seem to mention anything like this at all! I’d like to have a sneak preview!
References
- History of JavaScript concurrency model, see https://groups.google.com/forum/?hl=no#!topic/comp.lang.javascript/_356Apjy90k
- WebAppAPIs: HTML5. A vocabulary and associated APIs for HTML and XHTML, see http://www.w3.org/TR/html5/webappapis.html
- Mode-View-Controller (MVC), see http://en.wikipedia.org/wiki/Model_view_controller
- Document Object Model (DOM), see http://en.wikipedia.org/wiki/Document_Object_Model
- Understanding Model-View-Controller by Jeff Atwood, see http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html
- Document Object Model (DOM), see http://www.w3.org/DOM/
- Chrome OS on Wikipedia, see http://en.wikipedia.org/wiki/Chrome_os
- Web type «concurrency» and Go, see https://groups.google.com/forum/#!topic/golang-nuts/4llMzOgRsTY
- Real-time executive for 8051-type single-chip microcomputers, see http://www.teigfam.net/oyvind/pub/rtx-51/rtx-51.html#javascript
- Alan Kay on the meaning of «object oriented», a thread, see.http://occam-pi.org/list-archives/occam-com/msg03172.html. Simula-67 25 year’s anniversary, see: https://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/#Ref03
- Data, Context and Interaction on Wikipedia, see http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction
- «Life of occam-Pi» by Peter H. WELCH, School of Computing, University of Kent, UK at Communicating Process Architectures 2013 (CPA-2013)
http://www.wotug.org/papers/CPA-2013/Welch13a/Welch13a.pdf – Paper
http://www.wotug.org/papers/CPA-2013/Welch13a/Welch13a-slides.pdf – Presentation. Also referenced at https://www.teigfam.net/oyvind/home/technology/079-wysiwyg-semantics/#Ref03