Codesmiths: A humble proposal

Please post suggestions for improvement of Cinnamon here
Post Reply
Level 5
Level 5
Posts: 655
Joined: Sun Mar 10, 2013 8:08 pm
Location: Ohio (formerly California), USA

Codesmiths: A humble proposal

Post by markfilipak » Wed Mar 14, 2018 5:24 pm

I've been hacking some Cinnamon javascripts and have something to contribute.

Achronous [lacking-time]: non quantized (not clocked, as in analog).
Synchronous [same-time]: quantized (digital) with single, common clock @ fixed phase (or phase doesn't matter, as for serial chains without feedback).
Isochronous [equal-time]: quantized (digital) with single clock @ variable phase (and phase delay does matter, as when there's feedback).
Asynchronous [lacking-same-time]: quantized (digital) with multiple clocks of unrelated frequencies -- in a sense, asynchronous is a superset of isochronous.

Treating event handlers as synchronous clearly doesn't scale. Most of the crashes and lockups I've experienced appear to be synchronous accidents with an occurrence rate that's roughly proportional to the number of running tasks or threads. A common approach is to add small delays to event handlers in an attempt to test for and/or mitigate event collisions. That doesn't work in the long term -- it's not scaleable.

Systems need to have a way to degrade performance with increasing load without synchronous accidents. Isochronous control would be good approach, I think. But I believe the current development design approach is to create a messaging system that contains a queue with an implied clock (event time) as metadata. I think they'll find that a message system merely pushes the problem out to a slower running, supervisor process that negatively impacts system performance without fundamentally solving the problem.

In hardware design, we build dependable components that use a mix of synchronous & asynchronous logic (and achronous logic of course). Codesmiths happily don't need to address achronous logic at all, and provided they aren't trying to interface two or more computers, don't need to address asynchronous logic either (except possibly in device driver code if the hardware doesn't handle synchronization). Codesmiths need only address isochronous processes. The issue is this: How to transition from synchronous processes to isochronous processes.

It appears (from the "outside") that, in a sense, codesmiths are attempting to model isochronous processes from the bottom-up (that is, from the application interface). I think they will eventually find that fruitless. Hardware designers use a mix of state machines & synchronizers to solve such problems. State machines take care of the global logic (slow parts) with synchronizers taking care of the local logic (fast parts) -- think about building an event handler as a looping manager built from a continuously running case statement construct that has only one local variable: nextState, and that provides an expandable set of outputs based on an expandable set of inputs. I think my hardware (chip & system board) experience might be of service, but I don't know how to plug in. I could code a javascript model to demonstrate this, but I would need some assurance that the effort would be taken seriously.

By the way, as a necessary part of my background in chip & computer architecture, I've coded in many languages. You can get a rough idea of my background by looking at my profile on this forum.

Mark Filipak.

PS: Please don't refer me to github or slack or an IRC channel. If this forum supports private messaging, that would be fine. Otherwise, reply to this post.

User avatar
Level 18
Level 18
Posts: 8936
Joined: Fri Oct 12, 2012 9:44 pm
Location: Australian Antarctic Territory

Re: Codesmiths: A humble proposal

Post by catweazel » Thu Mar 15, 2018 1:59 am

markfilipak wrote:
Wed Mar 14, 2018 5:24 pm
PS: Please don't refer me to github or slack or an IRC channel.
¡uʍop ǝpısdn sı buıɥʇʎɹǝʌǝ os ɐıןɐɹʇsnɐ ɯoɹɟ ɯ,ı

Post Reply

Return to “Cinnamon”