The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <>
To: Lawrence Stewart <>
Cc: TUHS main list <>
Subject: Re: [TUHS] Threads vs... not
Date: Thu, 5 Aug 2021 16:02:06 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Aug 4, 2021, at 2:48 PM, Lawrence Stewart <> wrote:
> What do folks think about event-driven programming as a substitute for threads in UI and process control settings?

The equivalence here is with coroutines (sometimes called
green-threads), not true threads. True threads can take
advantage of multiple cores.  Your event-driven program won't
benefit from multiple cores.

> I wrote the service processor code for the Sicortex Machines using libevent.a and I thought it was very lightweight and fairly easy to think about. (This was a thing running on ucLinux on a tiny 16 MB coldfire that managed the consoles and power supplies and temp sensors and JTAG access and booting and so forth.)

I wrote the RealNetworks media server code using an
event-driven model.  It was efficient but the control flow got
quite messy as effectively my code had to do explicit
continuation passing. Given that each media stream was
independent of other streams, a thread based model was far
simpler.  That is what a colleague did to test the server

As a thought experiment consider implementing a Unix style
pipeline but without an OS that provides the illusion of
independent processes or threads and where each stage in the
pipeline is a separate function. Try implementing this in Go
which has support for threads vs C (but without pthreads).

I have used coroutines for hardware simulation a number of
times, the first time was in 1982 for simulating bus
transactions to see the impact of adding an ethernet
controller (5.6Mhz clock, memory access 4 clocks). The last
time was to simulate an ethernet switch with complex i/o
logic. One can think of each hardware module as a separate
state machine but smushing them into one giant state machine
would not been easy as the code was being developed and
debugging it would be very painful.  One would then be tempted
to write a "preprocessor" language of some sort to hide all

> Tk (IIRC) has a straightforward event driven model for UI interactions.
> Meanwhile, the dropbox plugin for my Mac has 120 threads running.  WTF?

Any system can be abused but the abuse-case should not be
mistaken for the normal use-case.

  parent reply	other threads:[~2021-08-05 23:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 21:48 Lawrence Stewart
2021-08-04 22:02 ` Larry McVoy
2021-08-04 22:41   ` John Cowan
2021-08-04 22:51     ` Larry McVoy
2021-08-05 20:32       ` Clem Cole
2021-08-06  0:55       ` Dan Cross
2021-08-04 22:13 ` Anthony Martin
2021-08-05 23:02 ` Bakul Shah [this message]
2021-08-06 14:19   ` Steffen Nurpmeso
2021-08-06 14:43     ` John Cowan
2021-08-06 15:12       ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).