Detecting at runtime when bindings go out of scope?

[David McClain]

… I think the notion of killing hung threads on dead channels originated in CML and carried over into Scheme. Both of those older systems used cheap Green Threads, and that encouraged a programming style wherein anything that needs doing, but might never complete, just fire off onto a new green thread.

In our case in Lisp with Native Threads, the threads are heavier objects and we need to minimize the gratuitous spawning of new threads. So my code errs on the side of loading up threads with a hefty amount of work whenever possible. Make them count, to amortize the cost in time and memory.

There is a sweet spot, if you can find it, in the throughput / delay curve, around the knee, just before it goes asymptotic. At maximum throughput, the delays stretch to infinity for any one task. Too many Native Threads will push you toward that asymptote.

- DM


> On Aug 26, 2016, at 16:06, David McClain <dbm at refined-audiometrics.com> wrote:
> 
> … also… on the Custodian concept — they forcibly shut down threads. I have also looked closely at how that plays out in application code, and it isn’t a given that when a thread is hung waiting on a channel that dies, killing the thread is the right thing to do. 
> 
> What I ended up doing in my Reppy Channels is that when a channel is discarded, the executive runs through the waiting queues and releases each of the waiting threads with a rendezvous failure indication. Let the thread resume running, and let it decide whether that warrants dying or not. In many cases there are still vital system structures that need cleaning up before that thread dies. Think of commit / rollback transactional processing...
> 
> So I don’t really like to abruptly terminate threads unless I must. In many ways, the old fashioned single-process Lisp was much easier to code. But the reality today is multi-thread on SMP processors, and I do love the speedup that you can gain from proper use of parallelism.
> 
> - DM
> 
>> On Aug 26, 2016, at 15:51, David McClain <dbm at refined-audiometrics.com> wrote:
>> 
>> Hi Ala,
>> 
>> Yes, I looked at the Custodian concept. Not quite what I have in mind. I implemented some Custodians in Lisp to see how they feel in the code. And as a last resort, that would certainly be a way to go. But the level of control is very coarse. I have the impression that Scheme does not have UNWIND-PROTECT.
>> 
>> And in a situation where you have literally thousands of ephemeral resource allocations between points of custodial interaction, then the custodian tables consume huge amounts of useless garbage that I’d prefer to hand back to GC. So really, GC, Finalization, and the ever-favorite UNWIND-PROTECT offer much finer grained control.
>> 
>> If you want to see the custodians, just give me a holler. They are free for the asking. Custodians.lisp
>> 
>> - DM
>> 
>>> On Aug 26, 2016, at 13:42, Ala'a Mohammad <amalawi at gmail.com> wrote:
>>> 
>>> Custodians from Racket looks like what is described
>>> https://docs.racket-lang.org/reference/eval-model.html#%28part._custodian-model%29
>>> 
>>> On Fri, Aug 26, 2016 at 5:51 PM, David McClain
>>> <dbm at refined-audiometrics.com> wrote:
>>>> Thanks for both of those references…. Dinosaur indeed… I’m old enough too,
>>>> that I need to avoid walking near the La Brea Tar Pits…
>>>> 
>>>> - DM
>>>> 
>>>> 
>>>> On Aug 26, 2016, at 06:42, Hans Hübner <hans.huebner at gmail.com> wrote:
>>>> 
>>>> The Lisp Machine Manual has a nice chapter on resources that may be of
>>>> interest: https://hanshuebner.github.io/lmman/resour.xml
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
>