stackless
— The built-in extension module¶
New in version 1.5.2.
The stackless
module is the way in which programmers must access
the enhanced functionality provided by Stackless-Python.
Functions¶
The main scheduling related functions:
-
stackless.
run
(timeout=0, threadblock=False, soft=False, ignore_nesting=False, totaltimeout=False)¶ When run without arguments, scheduling is cooperative. It us up to you to ensure your tasklets yield, perhaps by calling
schedule()
, giving other tasklets a turn to run. The scheduler will exit when there are no longer any runnable tasklets left within it. This might be because all the tasklets have exited, whether by completing or erroring, but it also might be because some are blocked on channels. You should not assume that whenrun()
exits, your tasklets have all run to completion, unless you know for sure that is how you structured your application.The optional argument timeout is primarily used to run the scheduler in a different manner, providing pre-emptive scheduling. A non-zero value indicates that as each tasklet is given a chance to run, it should only be allowed to run as long as the number of
|PY| virtual instructions
are below this value. If a tasklet hits this limit, then it is interrupted and the scheduler exits returning the now no longer scheduled tasklet to the caller.Example - run until 1000 opcodes have been executed:
interrupted_tasklet = stackless.run(1000) # interrupted_tasklet is no longer scheduled, reschedule it. interrupted_tasklet.insert() # Now run your custom logic. ...
The optional argument threadblock affects the way Stackless works when channels are used for communication between threads. Normally when the scheduler has no remaining tasklets to run besides the current one, the main tasklet is reawakened. By engaging this option, if there are other running Python® threads then the current one will instead block expecting them to eventually wake it up.
The optional argument soft affects how pre-emptive scheduling behaves. When a pre-emptive interruption would normally occur, instead of interrupting and returning the running tasklet, the scheduler exits at the next convenient scheduling moment.
The optional argument ignore_nesting affects the behaviour of the attribute
tasklet.nesting_level
on individual tasklets. If set, interrupts are allowed at any interpreter nesting level, causing the tasklet-level attribute to be ignored.The optional argument totaltimeout affects how pre-emptive scheduling behaves. Normally the scheduler is interrupted when any given tasklet has been running for timeout instructions. If a value is given for totaltimeout, instead the scheduler is interrupted when it has run for totaltimeout instructions.
This function can be called from any tasklet. When called without arguments, the calls nest so that the innermost call will return once the run-queue is emptied. Calls with a timeout argument however stack so that only the first one has any effect. Subsequent calls with timeout behave as though timeout were omitted. This allows a stackless application to be monitored on the outside without the inner application modifying the outer behaviour.
Note
The most common use of this function is to call it either without arguments, or with a value for timeout.
-
stackless.
schedule
(retval=stackless.current)¶ Yield execution of the currently running tasklet. When called, the tasklet is blocked and moved to the end of the chain of runnable tasklets. The next tasklet in the chain is executed next.
If your application employs cooperative scheduling and you do not use custom yielding mechanisms built around channels, you will most likely call this in your tasklets.
Example - typical usage of
schedule()
:stackless.schedule()
As illustrated in the example, the typical use of this function ignores both the optional argument retval and the return value. Note that as the variable name retval hints, the return value is the value of the optional argument.
-
stackless.
schedule_remove
(retval=stackless.current)¶ Yield execution of the currently running tasklet. When called, the tasklet is blocked and removed from the chain of runnable tasklets. The tasklet following calling tasklet in the chain is executed next.
The most likely reason to use this, rather than
schedule()
, is to build your own yielding primitive without using channels. This is where the otherwise ignored optional argument retval and the return value are useful.tasklet.tempval
is used to store the value to be returned, and as expected, when this function is called it is set to retval. Custom utility functions can take advantage of this and set a new value fortasklet.tempval
before reinserting the tasklet back into the scheduler.Example - a utility function:
def wait_for_result(): waiting_tasklets.append(stackless.current) return stackless.schedule_remove() def event_callback(result): for tasklet in waiting_tasklets: tasklet.tempval = result tasklet.insert() waiting_tasklets = [] def tasklet_function(): result = wait_for_result() print "received result", result
One drawback of this approach over channels, is that it bypasses the useful
tasklet.block_trap
attribute. The ability to guard against a tasklet being blocked on a channel, is in practice a useful ability to have.
Callback related functions:
-
stackless.
set_channel_callback
(callable)¶ Install a global channel callback. Every send or receive action will result in callable being called. Setting a value of
None
will result in the callback being disabled. The function returns the previous channel callback orNone
if none was installed.Example - installing a callback:
def channel_cb(channel, tasklet, sending, willblock): pass stackless.set_channel_callback(channel_cb)
The channel callback argument is the channel on which the action is being performed.
The tasklet callback argument is the tasklet that is performing the action on channel.
The sending callback argument is an integer, a non-zero value of which indicates that the channel action is a send rather than a receive.
The willblock callback argument is an integer, a non-zero value of which indicates that the channel action will result in tasklet being blocked on channel.
-
stackless.
get_channel_callback
()¶ Get the current global channel callback. The function returns the current channel callback or
None
if none was installed.
-
stackless.
set_schedule_callback
(callable)¶ Install a callback for scheduling. Every scheduling event, whether explicit or implicit, will result in callable being called. The function returns the previous channel callback or
None
if none was installed.Example - installing a callback:
def schedule_cb(prev, next): pass stackless.set_schedule_callback(callable)
The prev callback argument is the tasklet that was just running.
The next callback argument is the tasklet that is going to run now.
Note
During the execution of the scheduler callback the return value of
getcurrent()
and the value ofcurrent
are implementation defined. You are not allowed to execute any methods, that change the state of stackless for the current thread.
-
stackless.
get_schedule_callback
()¶ Get the current global schedule callback. The function returns the current schedule callback or
None
if none was installed.
Scheduler state introspection related functions:
-
stackless.
get_thread_info
(thread_id)¶ Return a tuple containing the threads main tasklet, current tasklet and run-count.
Example:
main_tasklet, current_tasklet, runcount = get_thread_info(thread_id)
-
stackless.
getcurrent
()¶ Return the currently executing tasklet of this thread.
-
stackless.
getmain
()¶ Return the main tasklet of this thread.
-
stackless.
getruncount
()¶ Return the number of currently runnable tasklets.
-
stackless.
switch_trap
(change)¶ modify the
switch trap
level. Returns its previous value.When the
switch trap
level is non-zero, any tasklet switching, e.g. due channel action or explicit, will result in aRuntimeError
being raised. This can be useful to demark code areas that are supposed to run without switching, e.g.:stackless.switch_trap(1) # increase the trap level try: my_function_that_shouldnt_switch() finally: stackless.switch_trap(-1)
Debugging related functions:
-
stackless.
enable_softswitch
(flag)¶ Control the switching behaviour. Tasklets can be either switched by moving C stack slices around or by avoiding stack changes at all. The latter is only possible in the top interpreter level. This flag exists once for the whole process. For inquiry only, use ‘None’ as the flag. By default, soft switching is enabled.
Example - safely disabling soft switching:
old_value = stackless.enable_softswitch(False) # Logic executed without soft switching. enable_softswitch(old_value)
Note
Disabling soft switching in this manner is exposed for timing and debugging purposes.
Attributes¶
Rather unusually, the module contains attributes for convenient access to some methods. Since this is not general practice and involves some hacks to attain, please consider this deprecated. Use the corresponding module functions instead.
-
stackless.
current
¶ The currently executing tasklet of this thread. Equivalent function:
getcurrent()
.
-
stackless.
runcount
¶ The number of currently runnable tasklets.
Example - usage:
>>> stackless.runcount 1
Note
The minimum value of
runcount
will be1
, as the calling tasklet will be included.Equivalent function:
getruncount()
.
-
stackless.
threads
¶ A list of all thread ids, starting with the id of the main thread.
Example - usage:
>>> stackless.threads [5148]
-
stackless.
pickle_with_tracing_state
¶ A boolean value, that indicates if a pickled tasklet contains information about the tracing and/or profiling state of the tasklet. By default
pickle_with_tracing_state
is False. Usually there’s no need to change this value.If you need to set this attribute on a per thread base, you can redefine the attribute as a thread local property:
>>> import stackless >>> import threading >>> stackless._pickle_with_tracing = threading.local() >>> stackless.__class__.pickle_with_tracing = \ ... property(fget=lambda m:getattr(m._pickle_with_tracing,'v',False), ... fset=lambda m,v:setattr(m._pickle_with_tracing, 'v', v), ... doc="thread local pickle_with_tracing flag")
Exceptions¶
-
exception
TaskletExit
¶ This exception is used to silently kill a tasklet. It should not be caught by your code, and along with other important exceptions like
SystemExit
, be propagated up to the scheduler.The following use of the
except
clause should be avoided:try: some_function() except: pass
This will catch every exception raised within it, including
TaskletExit
. Unless you guarantee you actually raise the exceptions that should reach the scheduler, you are better to useexcept
in the following manner:try: some_function() except Exception: pass
Here only the more common exceptions are caught, as the ones that should not be caught and discarded inherit from
BaseException
, rather thanException
.This class is derived from
SystemExit
. It is defind in the modulesexceptions
and__builtin__
.
Classes¶
-
class
stackless.
atomic
¶ This is a context manager class to help with setting up atomic sections.
Use it like this:
with stackless.atomic(): sensitive_function() other_sensitive_function()
Its definition is equivalent to the following, only faster:
@contextlib.contextmanager def atomic(): old = stackless.getcurrent().set_atomic(True) try: yield finally: stackless.getcurrent().set_atomic(old)