summaryrefslogtreecommitdiff
path: root/src/bytecode.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@redhat.com>2012-08-15 13:01:36 -0600
committerTom Tromey <tromey@redhat.com>2012-08-15 13:01:36 -0600
commit2d525b793f1b0fd2b6f66881310bec8684bceffe (patch)
tree932fb8b75974ac4c16ecfc5bc216fe362b0a4d27 /src/bytecode.c
parent68b32482437e05f0994c4dd0ab5b0c27d39f0f6d (diff)
downloademacs-2d525b793f1b0fd2b6f66881310bec8684bceffe.tar.gz
This parameterizes the GC a bit to make it thread-ready.
The basic idea is that whenever a thread "exits lisp" -- that is, releases the global lock in favor of another thread -- it must save its stack boundaries in the thread object. This way the boundaries are always available for marking. This is the purpose of flush_stack_call_func. I haven't tested this under all the possible GC configurations. There is a new FIXME in a spot that i didn't convert. Arguably all_threads should go in the previous patch.
Diffstat (limited to 'src/bytecode.c')
-rw-r--r--src/bytecode.c11
1 files changed, 4 insertions, 7 deletions
diff --git a/src/bytecode.c b/src/bytecode.c
index 019459491e9..d61e37d7886 100644
--- a/src/bytecode.c
+++ b/src/bytecode.c
@@ -335,12 +335,11 @@ struct byte_stack
#if BYTE_MARK_STACK
void
-mark_byte_stack (void)
+mark_byte_stack (struct byte_stack *stack)
{
- struct byte_stack *stack;
Lisp_Object *obj;
- for (stack = byte_stack_list; stack; stack = stack->next)
+ for (; stack; stack = stack->next)
{
/* If STACK->top is null here, this means there's an opcode in
Fbyte_code that wasn't expected to GC, but did. To find out
@@ -364,11 +363,9 @@ mark_byte_stack (void)
counters. Called when GC has completed. */
void
-unmark_byte_stack (void)
+unmark_byte_stack (struct byte_stack *stack)
{
- struct byte_stack *stack;
-
- for (stack = byte_stack_list; stack; stack = stack->next)
+ for (; stack; stack = stack->next)
{
if (stack->byte_string_start != SDATA (stack->byte_string))
{