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] |
Mikael Djurfeldt writes: > In Guile, at most places where we make new smobs, we have pieces of > code like this: > > SCM_NEWCELL (z); > SCM_DEFER_INTS; > SCM_SETCAR (z, scm_tc16_<name>); > SCM_SETCDR (z, <malloced memory>); > SCM_ALLOW_INTS; > > It seems to me that these critical sections can be removed (that is, > we can remove SCM_DEFER/ALLOW_INTS) if we remove one line (846) from > gc.c: [...] Rather, I suggest considering remove of all such critical regions protected by SCM_DEFER_INTS/SCM_ALLOW_INTS. Current design of signal handling in Guile is not so good, IMHO. In (current implementation of) Guile, the default behavior is allowing interrupts, which complicates many things. It's something like this: As interrupts are allowed almost anywhere, there are possible situations where interrupts messes it up. Watch out and protect yourself! I think this problem similars to dangling memory references in explicit GC scheme (with GCPRO/UNGCPRO). It's hard to preserve consisitency in the code, and it's very difficult to regenerate the problem and find actual bug. I'm sceptical and don't think that all critical regions are protected well. Not using heavily, we just haven't met the problem. In this summer, I posted here a little survey around signal handling in scripting languages. My conclusion was that the one in Python is good. Its defalut is masking all interrupts almost all the time and define explicitly the point to catch the interrupts. This makes it simpler. If we could define such well-defined interrupts point in Guile, I think that it's worth to considering remove of SCM_DEFER_INTS/SCM_ALLOW_INTS. Opinions? # Critical regions in threads environment is another issue... -- Niibe Yutaka