Title:

threadAttributes - an object representing the attributes used in creating a thread. These are values for parameters that control the run time behavior of the thread in terms of its competition for resources and what happens when it exits.

Slots:

priority:
the priority of this thread. Larger values imply greater importance.
detach:
logical value indicating whether the thread is 'detached' or 'non-detached'. A detached thread cannot be joined by another thread and disappears when it exits. The Evaluator Manager ignores its return value.
stackSize:
this should only be set by people who really know what they are doing at the level of the implementation of the C level threads.
This allows the user to set the space allocated for a thread's stack used for the evaluation of the C function calls in this thread. If this value is too small, a thread may run out of resources if it encounters several functions with a very large number of arguments or (I think) if the thread encounters a very deep sequence of function calls (such as recursion). If strange warning messages appear from the internal thread utilities, you can try changing increasing this value. Of course, the large this value, the fewer the number of threads as there is a fixed size for the resources shared by all the threads in a process.
connections:
a vector of 3 connection objects representing the input, output and error connections, in that order. Threads that read input from the user do so via the input connection, by default. Output from printing commands (print(), cat(), etc.) is written on the output connection. Warning and error messages are written to the error connection.

We note here that multiple threads writing to the same connection asynchronously could be very confusing and since the process has only one default stdout and stderr streams there is a problem. With the GUI library that is another part of this work, the threads can display their output in (potentially) separate "windows". For this purpose, we have certain widgets in different widget sets which can be coerced to be a connection with their own specialized printing methods. Namely we overload print(), etc. for these connection sub-classes.

access:
restrict write access to the task queue to certain types of threads. This argument can be one of several classes:
  • logical - if the value is F, no thread has write access to the task queue. If the value is T, all threads have access.
  • expression - the expression is evaluated when a thread attempts write to the task queue (via sendTask() of this thread. This expression is evaluated by the Evaluator Manager in its own environment.
  • threadGroup - one or more threadGroup objects can be passed supplied (individually, or in a list if more than one). If a thread is in one of these threadGroup objects at the time access is requested, it is granted by the Evaluator Manager
  • thread - one or more threads can be explicitly specified as having access to the task queue.
Note that all threads have read access to the task queue of any other thread. It is not important to restrict access to reading the queue. It might be useful to limit access to writing to the queue however.
cancel:
this defines how cancellation requests from other threads are handled. They can be ignored, or processed immediately or asynchronously at an appropriate time when all locks held by this thread have been released.
We have left out schedulePolicy for the moment as this is unlikely to be implemented in the near future. When Kernel level threads are implemented, we may revisit this option.

Constructors:

new("threadAttributes")
create the default threadAttributes object. This can be used in "all" normal instances of thread use. You may want to change the priority value.
threadAttributes()
allows any of the slot values to specified through an argument to this function and those supplied are merged into (and override) the default values from new("threadAttributes")

See Also:

thread

Examples:


Key Words:

User Level Threads

Last modified: Mon Feb 10 16:37:01 1997