3 ms·

I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equ

by Too 11y ago

I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equally unresponsive as as web worker not picking up messages. The alternative to message passing would be shared data structures and mutexes, not very nice.

Lerc 11y ago
A pre-emption mechanism would be able receive the message and respond. At the very least a response of "I'm busy" is better than no response that could be for any number of reasons. Shared data structures would enable this, and while you may not think they are very nice, I would prefer a not very nice solution to no solution whatsoever. I have seen discussions on various mailing that indicate that shared data structures will be implemented in some manner. Look at the example number crunching worker given in the spec. https://html.spec.whatwg.org/multipage/workers.html#a-background-number-crunching-worker https://html.spec.whatwg.org/multipage/workers.html#a-backgr... var n = 1; search: while (true) { n += 1; for (var i = 2; i <= Math.sqrt(n); i += 1) if (n % i == 0) continue search; // found a prime! postMessage(n); } How would you implement this worker in such a way that the host page could call worker.postMessage( {"command": "startfrom", "value" : 131071} ); to get the prime calculator change it's search point?
- geocar 11y ago
  Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.
  - Lerc 11y ago
    I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript. I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model. http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.ht...
    - geocar 11y ago
      You can get a lot of mileage out of specialised solutions, and I suspect we'll continue to see those instead of a shared model; in an answer to your question about finding prime numbers, simply kill the worker and start another one with a new initial state.
geocar 11y ago
There are many alternatives to "fire-and-forget message passing" that JavaScript does, that don't require shared data structures or mutexes. JavaScript can implement some of these alternatives with it's postMessage/onmessage combination, but it requires cooperation on both the sender and receiver which (in my opinion) is a limitation: The supervisor/operating system can expose just a little bit more information and it means the system isn't equally unresponsive anymore. Two that I'm thinking about are: • Mailboxes. A process can post a message to a remote buffer and also check the fullness of that buffer so it can make other arrangements (e.g. scheduling another worker, letting the user know that the system is busy, etc). JavaScript can simulate this if both sides cooperate by implementing an ack-on-receive. UNIX allows detection of a full-buffer (EWOULDBLOCK). KDB publishes[1] the number of bytes in the output buffers which would also be preferable to what JavaScript does. • Bulletin Boards. A process can simply publish information in a local buffer. Workers can then connect to pick up tasks. Again, JavaScript can simulate this if both sides cooperate, and implement a get/put system with postMessage/onmessage, and while this does represent a shared data structure, it's read-sharing which doesn't require any mutual-exclusion. You can also build it into a network protocol: My cexec[2] does this because load+network latency gives me free scheduling. Many mail servers also use this trick- one process writes to the queue directory, and workers pick up new work whenever they have time. If you're interested in inter-process communication, Tanenbaum gave good writeup[3] on these methods (which I think are specifically relevant), and some other methods (which are useful in other circumstances). [1]: http://code.kx.com/wiki/Reference/dotzdotW http://code.kx.com/wiki/Reference/dotzdotW [2]: https://github.com/geocar/cexec https://github.com/geocar/cexec [3]: http://www.amazon.co.uk/Modern-Operating-Systems-Andrew-Tanenbaum/dp/0138134596 http://www.amazon.co.uk/Modern-Operating-Systems-Andrew-Tane...
- Too 11y ago
  Good points, multiple workers on a single shared queue aren't exactly convenient with just a one way postMessage.

by Too 11y ago

Lerc 11y ago

A pre-emption mechanism would be able receive the message and respond. At the very least a response of "I'm busy" is better than no response that could be for any number of reasons. Shared data structures would enable this, and while you may not think they are very nice, I would prefer a not very nice solution to no solution whatsoever. I have seen discussions on various mailing that indicate that shared data structures will be implemented in some manner. Look at the example number crunching worker given in the spec. https://html.spec.whatwg.org/multipage/workers.html#a-background-number-crunching-worker https://html.spec.whatwg.org/multipage/workers.html#a-backgr... var n = 1; search: while (true) { n += 1; for (var i = 2; i <= Math.sqrt(n); i += 1) if (n % i == 0) continue search; // found a prime! postMessage(n); } How would you implement this worker in such a way that the host page could call worker.postMessage( {"command": "startfrom", "value" : 131071} ); to get the prime calculator change it's search point?

geocar 11y ago
Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.
- Lerc 11y ago
  I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript. I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model. http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.ht...
  - geocar 11y ago
    You can get a lot of mileage out of specialised solutions, and I suspect we'll continue to see those instead of a shared model; in an answer to your question about finding prime numbers, simply kill the worker and start another one with a new initial state.

geocar 11y ago

There are many alternatives to "fire-and-forget message passing" that JavaScript does, that don't require shared data structures or mutexes. JavaScript can implement some of these alternatives with it's postMessage/onmessage combination, but it requires cooperation on both the sender and receiver which (in my opinion) is a limitation: The supervisor/operating system can expose just a little bit more information and it means the system isn't equally unresponsive anymore. Two that I'm thinking about are: • Mailboxes. A process can post a message to a remote buffer and also check the fullness of that buffer so it can make other arrangements (e.g. scheduling another worker, letting the user know that the system is busy, etc). JavaScript can simulate this if both sides cooperate by implementing an ack-on-receive. UNIX allows detection of a full-buffer (EWOULDBLOCK). KDB publishes[1] the number of bytes in the output buffers which would also be preferable to what JavaScript does. • Bulletin Boards. A process can simply publish information in a local buffer. Workers can then connect to pick up tasks. Again, JavaScript can simulate this if both sides cooperate, and implement a get/put system with postMessage/onmessage, and while this does represent a shared data structure, it's read-sharing which doesn't require any mutual-exclusion. You can also build it into a network protocol: My cexec[2] does this because load+network latency gives me free scheduling. Many mail servers also use this trick- one process writes to the queue directory, and workers pick up new work whenever they have time. If you're interested in inter-process communication, Tanenbaum gave good writeup[3] on these methods (which I think are specifically relevant), and some other methods (which are useful in other circumstances). [1]: http://code.kx.com/wiki/Reference/dotzdotW http://code.kx.com/wiki/Reference/dotzdotW [2]: https://github.com/geocar/cexec https://github.com/geocar/cexec [3]: http://www.amazon.co.uk/Modern-Operating-Systems-Andrew-Tanenbaum/dp/0138134596 http://www.amazon.co.uk/Modern-Operating-Systems-Andrew-Tane...

Too 11y ago
Good points, multiple workers on a single shared queue aren't exactly convenient with just a one way postMessage.