Codesmiths: A humble proposal

Please post suggestions for improvement of Cinnamon on:
https://github.com/linuxmint/Cinnamon
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
markfilipak
Level 6
Level 6
Posts: 1173
Joined: Sun Mar 10, 2013 8:08 pm
Location: Mansfield, Ohio

Codesmiths: A humble proposal

Post by markfilipak »

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

Terms:
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.

Regards,
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.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
User avatar
catweazel
Level 19
Level 19
Posts: 9763
Joined: Fri Oct 12, 2012 9:44 pm
Location: Australian Antarctic Territory

Re: Codesmiths: A humble proposal

Post by catweazel »

markfilipak wrote: Wed Mar 14, 2018 5:24 pm PS: Please don't refer me to github or slack or an IRC channel.
Ok.
"There is, ultimately, only one truth -- cogito, ergo sum -- everything else is an assumption." - Me, my swansong.
Locked

Return to “Cinnamon”