1 comment

Discussion is closed. Login to edit/delete existing comments.

• 

  Jonathan Kirwan August 6, 2019 0

  Collapse this comment Copy link

  I'm surprised not to see comments here. You did a yeoman's job with this document and I very much want to thank you not only for it but for the rest of your outreach I've been exposed to, lately. (This includes an hour-long video I recently viewed made years ago.)
  I have been working on operating systems since around 1975 and I was able to work on the Unix v6 kernel in 1978, which is where I was first exposed to C (same year K&R's "The C Programming Language" came out came out, luckily for me.) Since then, aside from...

  Read more

  I’m surprised not to see comments here. You did a yeoman’s job with this document and I very much want to thank you not only for it but for the rest of your outreach I’ve been exposed to, lately. (This includes an hour-long video I recently viewed made years ago.)
  I have been working on operating systems since around 1975 and I was able to work on the Unix v6 kernel in 1978, which is where I was first exposed to C (same year K&R’s “The C Programming Language” came out came out, luckily for me.) Since then, aside from RSTS-11 and VAX VMS and the early days of Windows, I mostly wrote O/S code for embedded instrumentation. It got so that I could, from scratch without using any saved code base of mine, produce a working multi-threaded co-operative O/S with support for sleep and semaphore queues in one to two days under C. Of course, I’m talking about co-operative! Library issues would often, then, make pre-emptive thread switching a problem since the library code often used hidden static data.
  I often find that all I really want is a separate stack and a fast way to switch execution between very light-weight threads. I may want co-operative switching, for example, simply because I want the separate stacks to keep the code “clean and readable.” Pre-emption would make it even “cleaner” because I then wouldn’t even need a simple call to switch stacks. But I often don’t want the added costs required to make that work well. A simple call to switch stacks is all I often require. In pre-emption cases, the thread-switch code is a little more complex. But it’s not bad. (The main concern I have in that case will be the library resources I don’t write and how they operate.)
  What’s interesting to me, right now, is that it appears that under .NET and VB/C# there are only rather heavy-weight threads. A lot of grunt work takes place in creating, destroying, and switching between them. What I really want is a very simple programming model (the usual segments of CONST, CODE, INITIALIZED DATA, UNINITIALIZED DATA, HEAP, and STACK) and the ability to switch stacks within what .NET considers to be a Thread. In short, I’d like the programming conveniences of simple co-routine switching within a single .NET Thread. I’d need to be able to allocate separate stacks and to be able to switch between them; either co-operatively as a first step or pre-emptively using a timer resource as another step.
  I’ve also examined the simple details of interators and even these are excessively heavy to my view. I’ve implemented these using a method I first saw in a compiler written by Dr. DeRemer (of LALR parsing fame around 1970) and Dr. Pennelo (Metaware C.) In this case, the body of a “for” would be compiled as a nested function (with captures) and a link to this anonymous code body would be provided with a hidden parameter to the iterator function. The “yield” is just a call to the body with a visibility list. The stack depth is sustained during iteration, so all local variables continue to be held on the stack until the iterator completes when the stack unwinds naturally. Quite efficient.
  Regardless, thanks so much for the time you’ve offered me and others. It’s really appreciated. I also quite frankly love listening to your mind “sing” during the cases where I’ve watched you on video in front of an audience. Your mind outruns (in parallel interesting directions all at once) your ability to speak (which must, of course, be “serialized.”) And it’s wonderful to see and appreciate.
  Thanks, again.

  Read less