Date: 12 Mar 1998 11:53:14 -0000
Message-ID: <19980312115314.28961.qmail@hyperreal.org>
From: dgaudet@hyperreal.org
To: apache-1.3-cvs@hyperreal.org
Subject: cvs commit: apache-1.3/src/include http_main.h
Sender: apache-cvs-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

dgaudet     98/03/12 03:53:14

  Modified:    src/include http_main.h
  Log:
  document timeout stuff a bit more
  
  Revision  Changes    Path
  1.25      +15 -0     apache-1.3/src/include/http_main.h
  
  Index: http_main.h
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/src/include/http_main.h,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- http_main.h	1998/01/21 19:17:38	1.24
  +++ http_main.h	1998/03/12 11:53:13	1.25
  @@ -84,6 +84,21 @@
    * which might require it to be cleaned up; they * are, however,
    * implemented in http_main.c).
    *
  + * NOTE!  It's not "fair" for a hard_timeout to be in scope through calls
  + * across modules.  Your module code really has no idea what other modules may
  + * be present in the server, and they may not take too kindly to having a
  + * longjmp() happen -- it could result in corrupted state.  Heck they may not
  + * even take to kindly to a soft_timeout()... because it can cause EINTR to
  + * happen on pretty much any syscall, and unless all the libraries and modules
  + * in use are known to deal well with EINTR it could cause corruption as well.
  + * But things are likely to do much better with a soft_timeout in scope than a
  + * hard_timeout.
  + * 
  + * A module MAY NOT use a hard_timeout() across * sub_req_lookup_xxx()
  + * functions, or across run_sub_request() functions.  A module SHOULD NOT use a
  + * soft_timeout() in either of these cases, but sometimes there's just no
  + * choice.
  + *
    * kill_timeout() will disarm either variety of timeout.
    *
    * reset_timeout() resets the timeout in progress.