From: David Lichteblau <david@li...> - 2003-06-28 21:27:00
sb-bsd-sockets:socket-accept uses sb-sys:without-gcing. So with a
background thread blocking in the accept() call, SBCL never performs
garbage collection. Is there a workaround? Perhaps the sockaddr needs
to be replaced by malloc()ed data to make the call thread-safe?
From: Daniel Barlow <dan@te...> - 2003-06-30 15:54:36
=2D----BEGIN PGP SIGNED MESSAGE-----
David Lichteblau <david@...> writes:
> sb-bsd-sockets:socket-accept uses sb-sys:without-gcing. So with a
> background thread blocking in the accept() call, SBCL never performs
> garbage collection. Is there a workaround? Perhaps the sockaddr needs
> to be replaced by malloc()ed data to make the call thread-safe?
Thank you for spotting this: it hadn't occured to me that mujst be why
my experimental threaded araneida (which has 5 idle threads in
accept() at all but the busiest of times) is growing to silly
For GENCGC, I think - though I'm not entirely convinced yet - that we
don't really need the without-gcing wrapper at all: the sockaddr will
be on the C stack for the duration of the foreign call, so
preserve_pointers will mark it unmovable. The reason I'm not entirely
convinced is that my ailing memory says I added those wrappers when I
was first playing with threads, so at the time I must have been
thinking they'd fix something.
Cheney GC doesn't have unmovable pages, so that won't work, but as we
don't do threads on any cheney gc platform (nor are we likely to; at
least, I'm not offering) that might be less of an issue.
http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
=2D----END PGP SIGNATURE-----