Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Cyrus Harmon <slyrus@us...> - 2006-03-29 07:43:25
Update of /cvsroot/sbcl/sbcl/doc/internals-notes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6403/doc/internals-notes
* align stack to 16-bytes in arrange_return_to_lisp_function and skip padding
* updated bugs list and added debugging info for current blockers
* lots of debugging FSHOWs (many of these can go away once things work)
* restore buildability by adding missing #endif and #include "threads.h"
RCS file: /cvsroot/sbcl/sbcl/doc/internals-notes/Attic/x86-darwin-threads,v
retrieving revision 184.108.40.206
retrieving revision 220.127.116.11
diff -u -d -r18.104.22.168 -r22.214.171.124
--- x86-darwin-threads 27 Mar 2006 19:45:18 -0000 126.96.36.199
+++ x86-darwin-threads 29 Mar 2006 07:43:22 -0000 188.8.131.52
@@ -15,8 +15,12 @@
3. threads.impure.lisp and timer.impure.lisp fail.
-4. Leaking semaphores? (Perhaps same as 3) I think we leak semaphores
- at the moment.
+4. Leaking semaphores? I think we leak semaphores at the moment.
+5. Currently we'll die after 8192 total threads have been created. We
+ need to manage our own LDT to fix this until Apple fixes their
+ OS. i386_set_ldt LDT_AUTO_ALLOC doesn't reuse freed LDT's
@@ -73,7 +77,6 @@
the same place in the code in excuting threads.impure.lisp and
@@ -247,3 +250,19 @@
to 20 or so makes the situation better, but we still occasionally
fail, so there's some underlying problem we need to address.
+OTHER RANDOM NOTES
+1. Are we sure we're getting the stack alignment right deferred
+ signals? Could this be causing a problem for us?
+2. It's really too bad we can't step across an
+ EXC_BAD_ACCESS. (radar:4480172, closed, duplicate, who knows what
+ the non-duplicate bug number is)
+3. I'm not sure I get why lutexes work at all. What is the problem
+ that going to futexes (as opposed to just posix semaphores) solves
+ in the first place? It seems as though all we have is a wrapper
+ around posix sempahores. Is this good enough? Does it case
+ performance problems? Does it cause correctness problems?