From e4d24f3af1c0cd1664912d3277f3f728d75d27d4 Mon Sep 17 00:00:00 2001 From: Jim Blandy Date: Thu, 10 Oct 1996 00:52:21 +0000 Subject: [PATCH] * async.c (scm_take_signal): Doc fixes. --- libguile/async.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/libguile/async.c b/libguile/async.c index 739b4c29b..1409d155a 100644 --- a/libguile/async.c +++ b/libguile/async.c @@ -660,10 +660,18 @@ scm_take_signal (n) SCM ignored; if (!scm_ints_disabled) { - SCM_NEWCELL (ignored); /* In case we interrupted SCM_NEWCELL, - * throw out the possibly already allocated - * free cell. - */ + /* For reasons of speed, the SCM_NEWCELL macro doesn't defer + interrupts. Instead, it first sets its argument to point to + the first cell in the list, and then advances the freelist + pointer to the next cell. Now, if this procedure is + interrupted, the only anomalous state possible is to have + both SCM_NEWCELL's argument and scm_freelist pointing to the + same cell. To deal with this case, we always throw away the + first cell in scm_freelist here. + + At least, that's the theory. I'm not convinced that that's + the only anomalous path we need to worry about. */ + SCM_NEWCELL (ignored); } scm_system_async_mark (system_signal_asyncs[SCM_SIG_ORD(n)]); return SCM_BOOL_F;