В качестве контекста может использоваться любой пользовательский тип, и он будет передаваться последовательно в качестве параметра (
ctp
) во все последующие функции обслуживания потока.
block_func
— функция блокирования, которая вызывается в потоке сразу же после
context_alloc
или после очередного этапа выполнения потоком функции обработчика
handler_func
. Функция блокирования получает и возвращает далее обработчику (возможно, после модификации) структуру контекста (в приведенном выше примере контекстом является
int
— значение присоединенного TCP-сокета).
handler_func
— это, собственно, и есть аналог потоковой функции, в которой выполняется вся полезная работа потока. Функция вызывается библиотекой после выхода потока из блокирующей функции
block_func
, при этом функция-обработчик
handler_func
получит параметр контекста, возвращенный
block_func
.
В текущей реализации
handler_func
должна возвращать 0; все другие значения зарезервированы для дальнейших расширений. Аналогично определенная в атрибутной записи функция
unblock_func
зарезервирована для дальнейших расширений, и вместо ее адреса следует устанавливать
NULL
.
2. После создания атрибутной записи пула, определяющей всю функциональность его дальнейшего поведения, можно приступать к непосредственному созданию пула потоков:
thread_pool_t* thread_pool_create(
thread_pool_attr_t* attr, unsigned flags);
где
attr
— подробно рассмотренная (и созданная) ранее атрибутная запись пула;
flags
— флаг, определяющий поведение вызывающего потока после последующего вызова
thread_pool_start
. В документации описано два возможных значения флага:
•
POOL_FLAG_EXIT_SELF
— после старта пула поток, вызвавший
thread_pool_start
(часто это главный поток приложения), завершается;
•
POOL_FLAG_USE_SELF
— после старта пула поток, вызвавший
thread_pool_start
, включается в пул в качестве одного из его потоков.
И в том и в другом случае в типовом фрагменте (как и в показанном выше примере):
thread_pool_start(tpp);
exit(EXIT_SUCCESS);
управление никогда не дойдет до выполнения exit. Но существует еще третье допустимое значение, прямо не указанное в документации, но мельком упоминаемое в других местах документации:
•
0
— после старта пула поток, вызвавший
thread_pool_start
, продолжает свое естественное выполнение.
Например, некоторый фрагмент кода мог бы выглядеть так:
thread_pool_attr_t att; // ...
thread_pool_t *tpp = thread_pool_create(&attr, 0);
thread_pool_start(tpp);
while (true) {
// выполнять некоторую отличную от пула работу
}
exit(EXIT_SUCCESS);
Как уже понятно из описаний,
thread_pool_create
возвращает указатель на управляющую структуру пула потоков, которая позже будет передана
thread_pool_start
. Если создание пула завершилось неудачей, то результатом выполнения будет
NULL
, а в
errno
будет установлен код ошибки (документацией предусмотрен только один код ошибки:
ENOMEM
— недостаточно памяти для размещения структур данных).
Управляющая структура пула потоков описана так:
typedef struct _thread_pool thread_pool_t;
struct _thread_pool {
thread_pool_attr_t pool_attr;
unsigned created;
unsigned waiting;
unsigned flags;
unsigned reserved[3];
};
3. Последний шаг в процедуре запуска пула потоков:
int thread_pool_start(void* pool);
где
pool
— это указатель, возвращаемый
thread_pool_create
.
[40]
При успешном завершении (которого почти никогда не происходит, за исключением значения флага
0
; об этом см. выше) функция возвращает
EOK
, в противном случае (что происходит гораздо чаще) — значение
-1
.
4. Другие, относящиеся к библиотеке динамического пула потоков функции, которые целесообразно посмотреть в документации QNX (но которые в силу различных обстоятельств используются гораздо реже):
int thread_pool_destroy(thread_pool_t* pool);
int thread_pool_control(thread_pool_t* pool, thread_pool_attr_t* attr,