You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by dg...@hyperreal.org on 1998/03/12 12:53:14 UTC
cvs commit: apache-1.3/src/include http_main.h
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.