1. Task switching and state information
Wrapping task_yield() in order to perform a library-wide context switch is
a thing to do. However, this can lead to
performing a task switch when it isis not needed, as the new active task may
not use the library at all, or may not use any state information in it.
Hence some iverhead.
Another solution is for each routine which uses state information to check
whether the state information iss relative to the current task, and perform
the switch whenever they are different. This is probably good
performance-wise, but requires all the programmer's attention, as s/he
should put this code on entry to every routine which uses state information.
Perhaps a simpler way would be to define a new keyword, sat "task", used as
a prefix when declaring variables. A task variable would be local, and any
change to it would be reflected in the task's context.
For instance:
<eucide>
task integer fontSize
</eucode>
{{{
defines a local integer variable whose value depends on the active task. As
it is possible to tell at interpretation time which tasks will use which
libraries, the interpreter can optimise things so as to perform a context
switch for state information only when there's a chance for it to be
relevant.
Any thoughts?
CChris
2. Re: Task switching and state information
- Posted by Michael Nelson <mikestar13 at sbcglobal.net>
Sep 27, 2005
-
Last edited Sep 28, 2005
--0-1185223281-1127862205=:72080
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I am working on a small library that will automate wrapping task_yield to allow
multiple libraries to register procedures to be called before and after each task
switch. A library can also cancel a pending task switch. I need this in ME and
other lib authors may find it useful.
In summary, the lib will redefine task_yield and expose a global wrap_task_yield
procedure. The procedure will take two integer arguments: the routine id of a
library function to be called before the task switch, and the routine id of a
library procedure to be called after the task switch.
The before function will be passed the task ID of the task to be switched from
as a parameter and any return other than 0 will cause the cancellation of the
pending task switch.
The after procedure will be passed the task ID of the tasked swtiched to as a
parmeter.
[Perhaps these should be 0-argument routines and the library writer calls
task_self. Thoughts?]
Whne a program uses multiple libs that use wrap_task_yield, the before functions
will be called in the order in which the calls to wrap_task_yield occurred. The
after procedures will be called in reverse order.
If a before fucntion cancels task_yield, then the after procedures will be
called in reverse order beginning with the after procedure for the last library
whose befor fucntion was called prior to the cancellation.
An example: let's say our program includes in order foo.e and bare.e, two
libraries which both use wrap_task_yield.
When the redefined task_yield is called, first foo's before function is called
then bar's before function, then the task switch occurrs, then bar's after
procedure is called, then foo's after procedue is called.
If bar's before function cancels the task switch, foo's after procedure will be
called but bar's won't; if foo's before function cancels the task switch, no
after procedures will be called.
-- Mike Nelson
--0-1185223281-1127862205=:72080
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<DIV>
<DIV>I am working on a small library that will automate wrapping task_yield
to allow multiple libraries to register procedures to be called before and after
each task switch. A library can also cancel a pending task switch. I need this in
ME and other lib authors may find it useful.</DIV>
<DIV> </DIV>
<DIV>In summary, the lib will redefine task_yield and expose a global
wrap_task_yield procedure. The procedure will take two integer arguments: the
routine id of a library function to be called before the task switch, and the
routine id of a library procedure to be called after the task switch.</DIV>
<DIV> </DIV>
<DIV>The before function will be passed the task ID of the task to be switched
from as a parameter and any return other than 0 will cause the cancellation of
the pending task switch.</DIV>
<DIV> </DIV>
<DIV>The after procedure will be passed the task ID of the tasked swtiched to as
a parmeter.</DIV>
<DIV> </DIV>
<DIV>[Perhaps these should be 0-argument routines and the library writer calls
task_self. Thoughts?]</DIV>
<DIV> </DIV>
<DIV>Whne a program uses multiple libs that use wrap_task_yield, the before
functions will be called in the order in which the calls to wrap_task_yield
occurred. The after procedures will be called in reverse order. </DIV>
<DIV> </DIV>
<DIV>If a before fucntion cancels task_yield, then the after procedures will be
called in reverse order beginning with the after procedure for the last library
whose befor fucntion was called prior to the cancellation. </DIV>
<DIV> </DIV>
<DIV>An example: let's say our program includes in order foo.e and bare.e,
two libraries which both use wrap_task_yield. </DIV>
<DIV> </DIV>
<DIV>When the redefined task_yield is called, first foo's before function is
called then bar's before function, then the task switch occurrs, then bar's after
procedure is called, then foo's after procedue is called.</DIV>
<DIV> </DIV>
<DIV>If bar's before function cancels the task switch, foo's after procedure
will be called but bar's won't; if foo's before function cancels the task switch,
no after procedures will be called.</DIV>
<DIV> </DIV>
<DIV>-- Mike Nelson</DIV></DIV>
--0-1185223281-1127862205=:72080--
