I'm having a really hard time understanding your question.
If it's on the line of "signals only exist because we have time", then yeah, duh; and it's such an outrageous misconstruction of my comment that I imagine you meant something else.
If it's on the line of "signals only exist because we have time", then yeah, duh; and it's such an outrageous misconstruction of my comment that I imagine you meant something else.
This is what happens when your connection library starts a call-back after it connects; or blocks until the connection is ready; or use some continuation scheme, like futures to reorder your program and only start the next line of code after the connection is ready.
The alternative is what the article does. AFAIK, you can only do it in Javascript, because it's so obviously bad that no other language supports it.
For my example in circuitry, signal based synchronization uses a clock, or a ready signal. Time based synchronization just uses circuits that are ready to read data exactly when the previous step is done calculating it.
But clock is not a ready signal. The clock is just a periodical signal that keeps firing. If you squint your eyes, it is almost like an event loop performing a time.sleep(ns) before deciding to check the state. In the case of chips, the circuitry performs the next state transition after the very short delay decided by the periodical clock signal. The assumption that every pin would acquire a stable binary state before the next clock tick is a fundamental part of a chip design. Without that we'll have non-deterministic and ill-defined chip behavior.
The question is actually a rhetoric implying that "signalling" in the chip level involves time, namely, the clock signal that is firing periodically. It is not so much as a signalling as it is like an assumption baked into the circuit design. The circuit must change its state from one state to another only at the next clock signal and not before that.
usleep(100000); // give other thread enough time to do B
The fact that digital circuits operate by different parts all being synced to clock pulses, and some parts even count the pulses such that the 7th bit in a byte is actually picked out strictly by the timing of 7 pulses, is pointless pedantics when the article is operating in an entirely different domain which does not operate that way and there is cause & effect and the definition of a service being ready is when the service is ready, not any particular passage of time. The service might actually be ready before you even asked, or might still not be ready in an hour, or might have come up fully and gone back down all within the sleep.
Today the service takes 100ms to start and you have a 150ms sleep. Tomorrow the same service runs on faster hardware and takes 1ms to start, and now has it's own wrong timing assumption where when it starts, it shuts back down if there are no clients (stupid thing for most services to do, but people do stupid things all the time), it starts up and sleeps 50ms "to give time for the client". The 150ms sleeping client doesn't issue any requests, the service shuts back down.
You have to be writing the firmware to a spinning disk to talk about time being the actual definition of anything.
You seem to be talking about "events". We are not talking about events. We are talking about the clock component of CPU chips that keeps emitting a periodical signal.
> The passage of 150ms of time is not what makes thing B clear to proceed.
It absolutely does. Except that in modern chips the time interval is in nanoseconds. Two decades ago, it used to be in microseconds.
Not trying to be snarky but a genuine question: Do you have any background in chip design and fab? What @kazinator and I are saying is not exactly surprising. These things are taught in undergrad or grad-level integrated circuit courses.
If the circuitry didn't wait those nanoseconds before the next state change, it would be making the state change based on intermediate and possibly garbage values which would make the chip behave in a non-deterministic manner.
Again, we are not talking about events or cause-and-effect. We are talking about something that is more fundamental and is baked into the design of CPU chips at the very lowest level.