From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Cc: jantien@xs4all.nl, guile-devel@gnu.org
Subject: Re: stumped by scm_car/scm_cdr
Date: Fri, 8 Oct 2004 00:51:23 +0200 [thread overview]
Message-ID: <16741.51307.618175.489403@byrd.xs4all.nl> (raw)
In-Reply-To: <87ekkaxjmm.fsf@zagadka.ping.de>
mvo@zagadka.de writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> > I tried to remove all fishy looking places where SCM_C[AD]R were used,
> > and now it seems to work OK. You might want to consider just doing
> > abort() or a something similar as a standard.
>
> That would not fit SCM_CAR, SCM_CDR etc well. These macros are there
> for code that knows what it does and wants to do it fast. You can use
> SCM_DEBUG_CELL_ACCESSES to have them do some checks, however. These
> checks will only assert that you access a cell, not whether that cell
> represents a pair.
>
> In general Guile only aborts when there is no other way, for example
> when it has run out of memory or when the error reporting mechanism
> itself fails.
Ok. In that case, we should figure out why this could hang.
One thing that is fishy, is the fact that
void
scm_wrong_type_arg_msg
tries to call scm_list_2(), which will fail if GC is active.
I've added a check to scm_cell/scm_double_cell that calls abort() if
GC is running.
> So, we might talk about whether SCM_CAR and SCM_CDR should abort when
> passed a non-pair, or whether they should signal an error; or whether
> they should check that they are passed a cell.
No, I just don't want GUILE to ever hang. An error, ungraceful or not,
is always preferable. This probably fixes the cause, but wouldn't it
be better to check the thread handling as well? I guess that calling
scm_cell from GC causes a problem, because GC will (again) put all
threads to sleep.
--
Han-Wen Nienhuys | hanwen@xs4all.nl | http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2004-10-07 22:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 23:29 stumped by scm_car/scm_cdr Han-Wen Nienhuys
2004-09-25 15:54 ` Marius Vollmer
2004-09-25 23:19 ` Han-Wen Nienhuys
2004-09-29 15:37 ` Marius Vollmer
2004-10-06 23:44 ` Han-Wen Nienhuys
2004-10-07 18:52 ` Han-Wen Nienhuys
2004-10-07 21:55 ` Marius Vollmer
2004-10-07 22:12 ` Marius Vollmer
2004-10-07 22:51 ` Han-Wen Nienhuys [this message]
2004-10-07 23:41 ` Han-Wen Nienhuys
2004-10-18 17:47 ` Marius Vollmer
2004-10-24 12:25 ` Han-Wen Nienhuys
2004-11-04 16:49 ` Marius Vollmer
2004-11-08 6:48 ` Dirk Herrmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16741.51307.618175.489403@byrd.xs4all.nl \
--to=hanwen@xs4all.nl \
--cc=guile-devel@gnu.org \
--cc=jantien@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).