原创 2006年06月22日 10:31:00

#ifdef __cplusplus
extern "C" {

 * Routines in http_main.c which other code --- in particular modules ---
 * may want to call.  Right now, that's limited to timeout handling.
 * There are two functions which modules can call to trigger a timeout
 * (with the per-virtual-server timeout duration); these are hard_timeout
 * and soft_timeout.
 * The difference between the two is what happens when the timeout
 * expires (or earlier than that, if the client connection aborts) ---
 * a soft_timeout just puts the connection to the client in an
 * "aborted" state, which will cause http_protocol.c to stop trying to
 * talk to the client, but otherwise allows the code to continue normally.
 * hard_timeout(), by contrast, logs the request, and then aborts it
 * completely --- longjmp()ing out to the accept() loop in http_main.
 * Any resources tied into the request's resource pool will be cleaned up;
 * everything that isn't will leak.
 * soft_timeout() is recommended as a general rule, because it gives your
 * code a chance to clean up.  However, hard_timeout() may be the most
 * convenient way of dealing with timeouts waiting for some external
 * resource other than the client, if you can live with the restrictions.
 * (When a hard timeout is in scope, critical sections can be guarded
 * with block_alarms() and unblock_alarms() --- these are declared in
 * alloc.c because they are most often used in conjunction with
 * routines to allocate something or other, to make sure that the
 * cleanup does get registered before any alarm is allowed to happen
 * 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.

void ap_start_shutdown(void);
void ap_start_restart(int);
API_EXPORT(void) ap_hard_timeout(char *, request_rec *);
void ap_keepalive_timeout(char *, request_rec *);
API_EXPORT(void) ap_soft_timeout(char *, request_rec *);
API_EXPORT(void) ap_kill_timeout(request_rec *);
API_EXPORT(void) ap_reset_timeout(request_rec *);

API_EXPORT(void) ap_child_terminate(request_rec *r);
API_EXPORT(void) ap_sync_scoreboard_image(void);
int ap_update_child_status(int child_num, int status, request_rec *r);
void ap_time_process_request(int child_num, int status);
unsigned int ap_set_callback_and_alarm(void (*fn) (int), int x);
API_EXPORT(int) ap_check_alarm(void);

 * register an other_child -- a child which the main loop keeps track of
 * and knows it is different than the rest of the scoreboard.
 * pid is the pid of the child.
 * maintenance is a function that is invoked with a reason, the data
 * pointer passed here, and when appropriate a status result from waitpid().
 * write_fd is an fd that is probed for writing by select() if it is ever
 * unwritable, then maintenance is invoked with reason OC_REASON_UNWRITABLE.
 * This is useful for log pipe children, to know when they've blocked.  To
 * disable this feature, use -1 for write_fd.
API_EXPORT(void) ap_register_other_child(int pid,
       void (*maintenance) (int reason, void *data, ap_wait_t status), void *data,
                      int write_fd);
#define OC_REASON_DEATH        0    /* child has died, caller must call
                     * unregister still */
#define OC_REASON_UNWRITABLE    1    /* write_fd is unwritable */
#define OC_REASON_RESTART    2    /* a restart is occuring, perform
                     * any necessary cleanup (including
                     * sending a special signal to child)
#define OC_REASON_UNREGISTER    3    /* unregister has been called, do
                     * whatever is necessary (including
                     * kill the child) */
#define OC_REASON_LOST        4    /* somehow the child exited without
                     * us knowing ... buggy os? */

 * unregister an other_child.  Note that the data pointer is used here, and
 * is assumed to be unique per other_child.  This is because the pid and
 * write_fd are possibly killed off separately.
API_EXPORT(void) ap_unregister_other_child(void *data);


#ifdef __cplusplus

#endif    /* !APACHE_HTTP_MAIN_H */



/* (程序头部注释开始) * 程序的版权和版本声明部分 * Copyright (c) 2011, 烟台大学计算机学院学生 * All rights reserved. * 文件名称: ...


  • 2017年11月16日 10:54
  • 7KB
  • 下载


  • 2015年12月15日 18:49
  • 14KB
  • 下载


1、出现的问题:”error   LNK1169:   找到一个或多个多重定义的符号“的错误 2、该问题出现的场景:(假设有一个A.h,A.cpp,main,在main中调用了A.cpp文件中的函数,...

H264 main 级流程图

  • 2011年07月28日 10:45
  • 133KB
  • 下载

OS中 main.h 的一些基本概念 以及 类与对象的概念及其实现

目录: -头文件 #import -#include 与 #import 的区别 -OC语言的特点 -自动释放池 -面向对象的 特征 与 概念 ,以及其基本思想 -类 与 对象 的概念 -如何用OC中...

从零开始使用eclipse Ant脚本语言生成.h头文件:[javah] Exception in thread "main" java.lang.NullPointerException


简单通讯录的实现 main..h .m文件全部

// //  main.m //  OC - 数组作业 // //  Created by dllo on 15/10/28. //  Copyright (c) 201...