Re: [Chicken-hackers] [PATCH] Fix #1133

[Felix Winkelmann]

From: Oleg Kolosov <address@hidden>
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 01:33:25 +0400

> On 06/28/14 00:38, Felix Winkelmann wrote:
>>> Sounds like candidates for "lolevel subset" APIs. There are also a room
>>> for leveraging Chicken close relationship with C when optimizing code.
>>> We have some bottlenecks where Scheme is "too high level" but using its
>>> C API directly is too troublesome. It would be nice to have some more
>>> low level stuff conveniently exposed to Scheme side.
>> 
>> What stuff would you like to see?
> 
> More documentation for internals, even comments will do.

Well, that can be done. External documentation will quickly get out of
sync, but comments shouldn't be a problem. If there are particular
places where one could start, please tell.

> 
> More low level utilities for constructing complex data structures along
> the lines of record-instance. A ways to define high performance analogs
> of defstruct's update.

Do you mean high-performance analogs of functional update, for the
builtin records in the core system?

> 
> Some control for GC, with more direct support for ref-counted C
> structures for example. Or callbacks from native threads. I know about
> concurrent-native-callbacks, but it looks too magical to me. Maybe there
> are simpler way. It is said that finalizers hurt performance, maybe this
> can be improved with hints from C side (for FFI code).

concurrent-native-callbacks is actually pretty dumb: just a pipe and
some mutexes, and a dispatcher reading pointers from the pipe. Having
something more lightweight would certainly be nice, but will need even
more magical tricks and/or complex machinery. I'm really not familiar
enough with multithreading, but someone more experienced may be.

Finalizers have an impact on every GC, as every GC may free memory at
any time. What may be possible is to register finalizers only when it
is known that the associated data is not held in global variables. But
I'm not sure if it isn't in the end easier to manage the resources by
hand. On could do something like registerering and de-registering
finalizers temporarily (the former is O(1), the latter O(N), though).
Whether this buys anything, is another question, though.


felix