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