2016-06-27 14:56:38 +10:00
|
|
|
Copyright (C) 1999-2001, 2004, 2016 Internet Systems Consortium, Inc. ("ISC")
|
|
|
|
|
|
|
|
This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
2000-06-21 23:50:43 +00:00
|
|
|
|
2004-03-05 05:14:21 +00:00
|
|
|
$Id: tasks,v 1.7 2004/03/05 05:04:47 marka Exp $
|
2000-06-22 22:00:42 +00:00
|
|
|
|
2000-01-31 15:12:41 +00:00
|
|
|
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 explicity, 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
|
2000-03-14 04:10:42 +00:00
|
|
|
|
|
|
|
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 aquiring 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
|