标签：soc 管道 cti 环境 handler svr4 longjmp 私有 时间
State Thread 库可移植到大多数类 UNIX 平台上，但是该库有几个部分需要依赖于平台特性，以下列出了这些部分：
线程上下文初始化。
jmp_buf 数据结构的两个成员（程序计数器和堆栈指针）必须在创线程的时候进行手动设置。setjmp.h 文件中的
jmp_buf 数据结构在不同平台有不同的定义。一般，程序计数器是名字为 PC 的结构体成员，堆栈指针是名字为 SP
的结构体成员。可以参考 Netscape‘s NSPR library source 的源码。
注意，在一些 BSD 派生的平台上，应该使用 setjmp(3)/longjmp(3) 替代 _setjmp(3)/_longjmp(3)（这调用仅操作堆栈和
寄存器，不保存和恢复进程的信号掩码）。
Linux 上的 glibc 库 从 2.4 开始，被 setjmp(3)/longjmp(3) 使用的 jmp_buf 数据结构不能被直接访问（除非在程序执行
前设置特殊的环境变量 LD_POINTER_GUARD）。为了避免对特定环境的依赖，在所有的 Intel CPU 架构上 State
Threads 库提供了setjmp/longjmp 的替代函数。由于 setjmp/longjmp 在许多 CPU 架构上都是可用的，因此在其他 CPU
架构上也很容易被支持。
高精度的时间函数。
一些平台（IRIX, Solaris）提供了一个基于硬件计数器的高精度时间函数。该函数返回过去某一时刻（通常是机器启动
的时间）到现在的时间计数。它和一天的时刻无关，因此无法重置或清零。这对时间有高效、精准要求的任务十分有
用。
若一些特别的平台没有该函数，则可以使用 gettimeofday(3) 函数（尽管在某些平台上，该函数依赖于系统调用）。
堆栈的增长方向。
该库需要确定堆栈的增长方向是朝下（还是朝上）或者是往高内存地址。我们可以写一个测试程序检测该平台的堆栈增
长方向。
非阻塞特性继承。
在一些平台（如 IRIX），由 accept 调用创建的 socket 套接字继承监听套接字的非阻塞特性。我们可以使用测试程序或
用户手册来确认是否具有该特性。
匿名内存映射。
State Threads 库在开辟线程堆栈内存时，使用匿名内存映射（mmap(2)）。这个映射在 SVR4 和 BSD4.3 派生的平台
上有所不同。通过使用 malloc(3) 来进行堆栈分配可以避免内存映射，在这种情况下，应该定义 MALLOC_STACK 宏。
所有与机器相关的特性测试宏都应该在 md.h 头文件中定义。所有 CPU 架构的关于 setjmp/longjmp 替代函数的汇编代码都应该
放在 md.S 文件中。
当前版本的库已支持以下平台的移植：
使用 State Threads 的应用程序中信号的处理应该与传统的 UNIX 进程应用程序相同。这里没有每个线程的信号掩码，所有线
程共享同一个信号处理函数，并且在信号处理函数中只能使用异步信号安全的函数。当然，可通过将信号事件转换为 I/O 事件
的方法来支持同步信号。下面的代码演示了这种技巧（为了清晰起见，忽略了错误处理）：
/* Per-process pipe which is used as a signal queue. */
/* Up to PIPE_BUF/sizeof(int) signals can be queued up. */
int sig_pipe[2];
/* Signal catching function. */
/* Converts signal event to I/O event. */
void sig_catcher(int signo)
{
int err;
/* Save errno to restore it after the write() */
err = errno;
/* write() is reentrant/async-safe */
write(sig_pipe[1], &signo, sizeof(int));
errno = err;
}
/* Signal processing function. */
/* This is the "main" function of the signal processing thread. */
void *sig_process(void *arg)
{
st_netfd_t nfd;
int signo;
nfd = st_netfd_open(sig_pipe[0]);
for ( ;; ) {
/* Read the next signal from the pipe */
st_read(nfd, &signo, sizeof(int), ST_UTIME_NO_TIMEOUT);
/* Process signal synchronously */
switch (signo) {
case SIGHUP:
/* do something here - reread config files, etc. */
break;
case SIGTERM:
/* do something here - cleanup, etc. */
break;
/**
* Other signals
*/
}
}
return NULL;
}
int main(int argc, char *argv[])
{
struct sigaction sa;
...
/* Create signal pipe */
pipe(sig_pipe);
/* Create signal processing thread */
st_thread_create(sig_process, NULL, 0, 0);
/* Install sig_catcher() as a signal handler */
sa.sa_handler = sig_catcher;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGHUP, &sa, NULL);
sa.sa_handler = sig_catcher;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGTERM, &sa, NULL);
...
}注意，如果使用了多个进程（看下面），信号管道应该在调用 fork(2) 之后进行初始化，以便每个进程都可以有自己的私有
管道。
由于库 scheduler 的事件驱动特性，线程上下文切换（进程状态改变）只能在一组众所周知的库函数中发生。这个集合包含
一个线程可以阻塞的函数：I/O 函数（st_read(), st_write(), etc），sleep 函数（st_sleep()，etc），还有线程同步
函数（st_thread_join(), st_conf_wait()，etc）。因此，特定于进程的全局数据不需要被锁保护，因为线程不会在关键的部
分被重新调度（同一时刻只有一个线程可以访问相同的内存位置）。出于同样地原因，非线程安全的函数（在传统意义上）
可以被 State Threads 安全地使用。对于一个正确编写的应用程序（在关键部分没有阻塞函数），库的 mutex 实际上是没有
作用的，主要是为了提供完整性。锁的缺失极大的简化了应用程序的设计，并未可伸缩性提供了基础。
State Threads 库可以将大量的并发连接转换成更少的单独进程，其中每个进程使用一个多对一的用户级线程实现（M:1 的 N
个映射而不是在某些平台上本地线程库使用的一个 M:N 的映射）。这种设计是应用程序可伸缩性的关键。可以这样想，好像
一组所有的线程都被划分为单独的组（进程），其中每个组都有一个单独的资源池（虚拟地址空间、文件描述符等）。应用程
序设计者完全控制应用程序创建的组（进程）的数量，以及通过标准 UNIX 进程间通信（IPC）在不同组间共享的资源。
创建多个进程有以下几个原因：
理想情况下，所有的用户会话都是完全独立的，因此不需要进程间通信。最好有几个独立的更小的特定于进程的资源（例如，
数据缓存），而不是所有进程共享一个大的资源。然而，有时需要在不同的进程间共享一个公共的资源。在这种情况下，可以
使用标准的 UNIX IPC。除此之外，还有一种方法可以同步不同的进程，这样只有当资源不可用时，访问共享资源的线程才会
被暂停（而不是整个进程）。在以下代码片段中，一个管道用作进程间同步的计数信号量：
#ifndef PIPE_BUF
#define PIPE_BUF 512 /* POSIX */
#endif
/* Semaphore data structure */
typedef struct ipc_sem {
st_netfd_t rdfd; /* read descriptor */
st_netfd_t wrfd; /* write descriptor */
}ipc_sem_t;
/* Create and initialize the semaphore. Should be called before fork(2). */
/* ‘value‘ must be less than PIPE_BUF. */
/* If ‘value‘ is 1, the semaphore works as mutex. */
ipc_sem_t *ipc_sem_create(int value)
{
ipc_sem_t *sem;
int p[2];
char b[PIPE_BUF];
/* Error checking is omitted for clarity */
sem = malloc(sizeof(ipc_sem_t));
/* Create the pipe */
pipe(p);
sem->rdfd = st_netfd_open(p[0]);
sem->wrfd = st_netfd_open(p[1]);
/* Initalize the semaphore: put ‘value‘ bytes into the pipe */
write(p[1], b, value);
return sem;
}
/* Try to decrement the "value" of the semaphore. */
/* If "value" is 0, the calling thread blocks on the semaphore. */
int ipc_sem_wait(ipc_sem_t *sem)
{
char c;
/* Read one byte from the pipe */
if (st_read(sem->rdfd, &c, 1, ST_UTIME_NO_TIMEOUT) != 1)
return -1;
return 0;
}
/* Increment the "value" of the semaphore */
int ipc_sem_post(ipc_sem_t *sem)
{
char c;
if (st_write(sem->wrfd, &c, 1, ST_UTIME_NO_TIMEOUT) != 1)
return -1;
return 0;
}通常，使用 State Threads 库编写应用程序的时候应该遵循以下步骤：
State Threads 体系结构使用 st_netfd_t 对象上的非阻塞 I/O 来并发处理多个用户连接。这种体系结构有一个缺点：整个进程
及其所有线程可能会在磁盘或其他非网络 I/O 操作期间阻塞，无论是通过 State Threads I/O 函数，直接系统调用，或者标准
I/O 函数。（这主要适用于磁盘读；磁盘写通常是异步执行的 -- 数据先写入到 buffer 缓存，然后再被写入到磁盘。）辛运的
是，磁盘 I/O（不像网络 I/O）通常需要一个有限且可预测的时间，但对于特殊设备或用户输入设备（包括 stdin）可能不适
用。然而，这样的 I/O 减少了系统的吞吐量，并增加了响应时间。有几种方法可以设计一个应用程序来避免这种缺点：
st_cond_timedwait() 和 I/O 函数的超时参数，以及 st_sleep() 和 st_usleep() 的参数指定了自函数调用开始后的最后一次
上下文切换之后等待的最长时间。
State Threads 的时间分辨率实际上是上下文切换之间的时间间隔。在某些情况下，这个时间间隔可能很大，例如，当单个线程
连续执行大量工作时。注意，一个稳定的、不间断的网络 I/O 流符合这个描述；只有在线程阻塞时才会发生上下文切换。
如果指定的 I/O 超时小于上下文切换之间的时间间隔，则该函数可能会在函数开始调用后经过该时间量（指上下文切换的时间
间隔）之前返回超时错误。例如，如果自上一次上下文切换后已经过去了 8 ms，超时时间为 10 ms 的 I/O 函数可能会导致一
次切换，则在该函数调用后的 2 ms 返回一个超时错误（在 Linux 上，select() 的超时时间是 select() 返回前经过的时间的
上限）。同样，如果已经过去了 12 ms，函数可能立即返回。在几乎所有的情况下，I/O 超时应仅用于检测断开的网络连接或者
防止对方长时间保持空闲连接。因此，对于大多数应用程序来说，实际的 I/O 超时应该在几秒钟内。此外，重试超时操作可能
没有意义，也不要重试使用一个简单的更大的超时。
最大的有效超时值取决于平台，并且可能会显著的小于 select() 的 INT_MAX 秒 或 poll() 的 INT_MAX 毫秒。一般情况下，
你不应该使用超过几个小时的超时。使用 ST_UTIME_NO_TIMEOUT(-1) 作为一个特殊值来指示无限超时或者无限期休眠。使
用 ST_UTIME_NO_WAIT(0) 来指示不等待。
标签：soc 管道 cti 环境 handler svr4 longjmp 私有 时间
原文地址：https://www.cnblogs.com/jimodetiantang/p/9019978.html
