[191] in Pthreads mailing list archive
pthreads
daemon@ATHENA.MIT.EDU (Tom Lord)
Wed Nov 1 20:42:05 1995
Date: Wed, 1 Nov 1995 18:17:51 -0800
From: Tom Lord <lord@beehive.cygnus.com>
To: grib@cs.utexas.edu
Cc: gel@cygnus.com, pthreads@MIT.EDU
Reply-To: lord@cygnus.com
Hi.
Thanks for the valuable work you are doing. Can i please, soon, get a
copy of the code? I was intending to do exactly what it sounds like
you are doing, perhaps i can help with your code.
I suspect the problems you are having relate to a bad interaction
between the multiple stacks maintained by pthreads, and the
conservative sweep of the C stack during Guile's mark phase of GC.
The error message you got most likely indicates that a live object was
collected.
The error message probably comes from just *after* GC when some object
that has been overwritten with a free cell is used. The error message
says:
ERROR: Wrong type argument in position 1 to apply: #<unknown-type
(0x7f . 0x175748) @ 0x175750>
That means that there was a strange object in the cons-pair heap at
address 0x175750 and that its CAR was 0x7f, which happens to be the
tag "scm_tc_free_cell".
127 is also the tag of a "smob" if you forget to initialize the
variable that holds the smob table index (e.g. tc16_foo). If you
don't know what that means, it probably isn't the problem.
The reason why a live object might be collected when using pthreads is
that when GC is invoked, it only knows to search the active C stack
(and any heap-allocated continuation stacks, of course). In
particular, it does not know to look at C stacks of threads that
aren't running or that, worse, are running during GC.
Assuming that the bad interaction between pthread stacks and GC is to
blame, the fix is two-fold. First, we must make sure that GC does not
run while *any* thread is in the middle of a Guile critical section
(one between DEFER_INTS and ALLOW_INTS). Second, we must make sure
that *all* of the pthreads stacks on which there are Guile-related
frames are scanned by the mark phase of GC. I think these are
both easy to do.
Another problem you are likely to encounter that is not GC related
concerns what happens if two concurrent threads enter critical
sections concurrently -- you lose. For now, the simplest thing is to
have Guile threads switch explictly and only during execution of
ALLOW_INTS.
-t
