This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
From: Greg Harvey <Greg.Harvey@thezone.net>
>It would be easier, if you're going to end up mallocing the memory
>anyway, to create a new scheme type for the thing you want to alloca
>(if it contains scheme objects... if it doesn't, you don't have to
>care, so alloca like mad), and let the gc clean things up for you;
>that's it's job, after all. Adding the special case code to handle the
>portable alloca in the gc, for the benefit of one place in the code,
>seems to me like a lot of wasted work to get the same behaviour. Now,
>what's really needed is to have the smob space increased, so you don't
>have to worry about exhausting smobs while doing this (is anybody
>currently working on this? I seem to recall this was supposed to be a
>Real Soon Now(tm) thing after the 1.3 release).
I completely agree with Greg here. Leveraging the existing smob system is
much simpler than adding a new special case for the gc.
Two small questions...
1. What are the limits on the current smob space, BTW?
2. Is there any way of implementing a truly portable alloca, where all the
memory is on the stack?
Neil