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] |
Perry asked: > Is not being able to relocate memory/perform modern garbage > collection/handle reentrancy/etc. really worth the simplicity the > conservative GC provides? That's not the tradeoff we have. You can have incremental, generational, multithreaded conservative GC. Guile's GC isn't any harder to make thread-friendly than any other GC; they're just all bitchin' hard. Conservative GC prohibits you from copying some objects. But there are lots of ways to work around that limitation. For example, there's no intrinsic connection between copying GC's and generational GC's. And you can have "mostly-copying" collectors (if you think Compaq is not going to sue you for violating the patent they inherited from DEC). Conservative GC imposes one other burden: at the moment, you can't use Guile in a multithreaded program even if you guarantee (with locks or whatever) that only one thread will invoke a Guile function at a time. That's pretty weird; most libraries will let you do that. But this restriction arises because Guile wants to know where all the stacks are. That's unusual. However, this requirement is probably easy to meet, using some knowledge of the underlying thread system. This difficulty is minor compared with the other problems involved in multithreaded GC.