Re: [Chicken-users] another proposal to modify runtime.c

[Jörg F . Wittenberger]

On Sep 28 2011, Alan Post wrote:

> I've heard this called a "dummy head" list.  I didn't think people
> wrote linked list code any other way...  You use one extra cons
> cell and remove all the beginning of list checks you'd otherwise
> require.
>
> I thought this part came standard.  ;-)  Good catch.  It's a trick
> I've been able to use well outside of C programming.  Heck, I think
> my egg, genturfahi, uses this one somewhere.

Thanks for the warm welcome Alan,

I'm afraid I have to tell you an unfortunate truth: there is more of
this at spots I'd consider critical.

For instance: in scheduler.scm there's a timeout queue.  Last time I
checked it carried a comment that this needs a better implementation.

But: there is hope that nobody needs to step up and dive into that code.
Long time ago I modified scheduler.scm and srfi-18.scm in my code base.
I replaced both the timeout queue and the fd-list with a binary search
tree (a left leaning red black tree that is).

I don't think it's possible to run a peer of an Askemos network
(see ball.askemos.org) reasonably without those modifications.
(But I did not check since.)

Further I recall that I fixed a bug or two in srfi-18 -- but at top of
my modifications and before I took the experiment at that time under
source control.  Sadly I can't recall what the problem was.

At this time I dare to advertise my modifications as well tested.  Billions
of threads per process life time are well handled.

However I might need some help to properly feed those changes back.

One consideration is: as it is now, it works quite well.  But I see
more simplifications ahead.  Maybe it's the best to integrate the well
tested state of affairs now and have me tampering later.

At the other hand I understand that this would be a non-trivial 
modification. It might be better to find some testers on a separate git 
branch. So much for the personal help: I'm so far git-illiterate.

Best Regards
/Jörg

PS: I recalled that I once noticed that the gc_root allocation/deallocation
would be one more thing to avoid.

Now the way I'm running sqlite in a separate pthread to keep the chicken
thread responsive (and available to feed data blocks from the DHS to
sqlite's virtual file system) I came to need a gc_root.  Actually I
do need that only while sqlite is actually active.  However the handling
overhead made me write a weird alternative, where I keep one gc_root
active as long as the database connection is open.  This however does
obviously add overhead to each and every major garbage collection.

If there's no better proposal in the next time, I'll come up with a patch
to use a allocation strategy in parallel to the finalizer implementation
for gc_roots.