1
0
mirror of https://gitlab.isc.org/isc-projects/bind9.git synced 2025-04-18 09:44:09 +03:00
bind9/doc/design/tasks
2020-02-21 15:05:08 +11:00

71 lines
1.9 KiB
Plaintext

Copyright (C) Internet Systems Consortium, Inc. ("ISC")
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
Changes I made last week to the task code simplified the task shutdown
and termination model. Here's how things now work:
When a task is shutdown:
Any "on shutdown" events for the task are posted
The "shutting down" attribute of the task is set
Any attempts to add shutdown events with isc_task_onshutdown()
will fail, since the task is already shutting down
Task shutdown can be initiated explicitly, via a call to isc_task_shutdown(),
or implicitly, when the following conditions occur:
The "shutting down" attribute of the task is not set
The task has no references
The task has an empty event queue
Task termination occurs when:
The "shutting down" attribute of the task is set
The task has no references
The task has an empty event queue
Notes from the task/event discussion led by Bob Halley on 13 March 2000:
A task is an event queue.
(task) --V
(event)-->(event)-->(event)
(runnable queue)--V
(task)-->(task)-->(task)
Normally only one task manager in an application.
Task becomes runnable if it has a non-empty event queue.
One or more worker threads run tasks.
Event routines should be relatively short.
Only one runnable queue that all workers share.
Events for a task are always posted serially. Multiple worker threads
will not be working on multiple events for one task at the same time.
isc_event_send, posting an event, can't fail. It just adds an event
to the task queue.
Event action (callback) rules:
* no locks held on your behald when entering a callback.
* not allowed to block, except when acquiring a lock.
* not allowed to hold a lock when exiting the callback.
TIMERS?
OMAPI -- need taskmgr to omapi_lib_init
-- one task per client connection