You know, I got an A in my "Principles of Operating Systems" class

last quarter.  Ain't worth a cent now.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92715 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/STATUS b/STATUS
index 4426c07b3ab5698e745528979b0f6aededc16cb2..561fbcd67e566b2e5321414cba06393e090efd35 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE 2.0 STATUS:                                             -*-text-*-
-Last modified at [$Date: 2002/01/02 19:34:47 $]
+Last modified at [$Date: 2002/01/03 09:53:37 $]
 
 Release:
 
@@ -149,6 +149,18 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
                  hang. My theory is that this has to do with the
                  pthread_cond_*() implementation in FreeBSD, but it's still
                  possible that it is in APR.
+    Justin adds: Oh, FreeBSD threads are implemented entirely with 
+                 select()/poll()/longjmp().  Welcome to the nightmare.
+                 So, that means a ktrace output also has the thread 
+                 scheduling internals in it (since it is all the same to 
+                 the kernel).  Which makes it hard to distinguish between 
+                 our select() calls and their select() calls.  
+                 *bangs head on wall repeatedly*  But, some of the libc_r 
+                 files have a DBG_MSG #define.  This is moderately helpful
+                 when used with -DNO_DETACH.  The kernel scheduler isn't 
+                 waking up the threads on a select().  Yum.  And, I bet 
+                 those decrementing select calls have to do with the 
+                 scheduler.  Time to brush up on our OS fundamentals.
      
     * There is increasing demand from module writers for an API
       that will allow them to control the server à la apachectl.