This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: Upcoming 1.3.2 release
Greg Harvey <Greg.Harvey@thezone.net> writes:
> The problem isn't so much that it could be problematic to call scheme
> code, but pretty much anything in guile is suspect (except scm_cons &
> newcell, because we know that'll screw things up). A set of predefined
> behaviours could work, but you'd want to watch out for something like
> the second, since you can't reliably call things like display & stuff
> like that... you could do writes on the underlying fd, if you don't
> have to worry about buffering (or don't care about slightly odd
> output), though. I'll add a bit to allow registering c functions to
> my gc code, but I do think it'd be a really bad idea to add a general
> hook for this.
Sorry for not noticing the implications.
However, I do like the idea of using hooks from all other aspects.
And I think it's a good idea to try hard to get rid of extra
mechanisms for specific purposes.
What about reserving a pool of conses which is made available to
NEWCELL during special conditions like this? (There's still the
problem with malloced memory.) The size of this pool could be a
settable parameter.
Also, note that if only well-behaved C functions, wrapped as
scm_tc7_subr_0:s, are added to before-gc-hook, no conses will be used,
so it's still possible to use the hook mechanism.