From: Justin Erenkrantz <jerenkrantz@apache.org>
Date: Thu, 3 Jan 2002 09:53:37 +0000 (+0000)
Subject: You know, I got an A in my "Principles of Operating Systems" class
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=252749ab8a8e39acb1da5a9f7d21d31b7c7d1d85;p=apache

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 4426c07b3a..561fbcd67e 100644
--- 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.