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] |
Christian Lynbech <chl@tbit.dk> writes: > >>>>> "Greg" == Greg Harvey <Greg.Harvey@thezone.net> writes: > > Greg> ... also referenced by other stack variables; it shouldn't be a > Greg> problem, but it also doesn't fill me with confidence. > > Exactly our feelings. > > Moreover, a colleague also pointed that it may be even worse. The > portable alloca implementation expects to be called frequently > (perhaps just as alloca(0)) in order to be able to clean up. As I > understand it, it examines stack pointers to see if some of the alloca > frames need to be freed, I think this entire problem is not that hard to solve. AFAIK, portable alloca maintains internal list of all allocated memory blocks. If we make the garbage collector checking this blocks as if they were on the stack then all will be ok. The gc should also check whether this blocks are "above" or "below" the top of the stack. It might clean up allocated memory itself or just call alloca(0). > but will this work with a multithreaded > application which has several stack spread out across the memory? Hmm... Does guile work this way? I mean, can gc currently handle multiple stacks? -- Aleksey Demakov avd@gcom.ru