スレッド

デフォルトでインターフェース定義はどれも単一のスレッド内で実行され，また，現在のところGUIKit`定義はランタイムでJavaコンポーネントとして実行されるので，この実行は単一のJava AWTイベントディスパッチスレッドで起るということになる．

ほとんどの場合，完全なユーザインターフェースダイアログあるいはツールを単一のJavaスレッドで実行し，Wolfram言語に同期要求を送りることができる．要求をどのように進めるかの明示的なスレッドコードは必要ない．また，Wolfram言語カーネルはマルチスレッドではないので，マルチスレッドのインターフェース定義を行おうと試みる唯一の理由は，Wolfram言語内でログの計算が行われている間にユーザインターフェースの更新を行うためである．

例えば，次の定義を考えてみよう．

この定義が描画するスクリーンショットを撮る．

この例題を実行しようとしてボタンを押しても，このラベルのテキストが更新される模様は実際は見られない．何故か．ボタンにバインドされたイベントがデフォルトの単一AWTスレッドで実行されていてこの実行（アクションの呼出し）中にユーザインターフェースは使用中であり，一方ラベルのテキストを設定しようという試みはすべてScriptコードから行われているからである．ユーザインターフェーススレッドはボタンアクションの呼出し評価をしており，ラベルテキストの更新やウィンドウの再描画といったその他の要求を受け取ることはできない．Wolfram言語で時間がかかる計算が行われている間にユーザインターフェースを更新したければ，新たなスレッドで非同期的にBindEventコードを実行し，ユーザインターフェースイベントディスパッチスレッドが使用可能で他のユーザインターフェースのウィジェットの更新要求を受けることができるようにする必要があるだろう．しかし，ここには満足しなければならない重要で付随的な必要事項がある．ユーザインターフェースウィジェットはAWTイベントディスパッチスレッド以外のスレッドの呼出しによって更新することはできないので，SetPropertyValueからのこのようなウィジェット更新の要求は，AWTイベントディスパッチスレッドで行われキューされ，実行されなければならない．

GUIKit は新たな別個のスレッドで実行を引き起すことに関連した問題を簡略しようと試みる．また，ある種の実行が必要であれば必ずAWTイベントディスパッチスレッドで行われるようにする．BindEvent，SetPropertyValue，InvokeMethod等の GUIKit の実行関数の多くが2つのオプションを取る．その一方はInvokeThread -> "Name"で，これは断片的なコードをどこで実行するかを決定する．もう一方はInvokeWait -> Automatic | True | Falseで，これはこの新たなリクエストを開始するスレッドが，多分異なるスレッドで，続行する前にこの新たなリクエストからの応答が終了するまで待つか，あるいはあらゆる応答を無視して直ちに実行を続行するかを決定する．

InvokeThreadは現在のところ"Current"（デフォルト），"New"，"Dispatch"の3つの値を受け付ける．"Current"を選ぶとリクエストを実行する新たなスレッドを作ろうという試みは行わず，同じ現行のアクティブなスレッドで実行する．"New"は新たなスレッドを作り，この新たなスレッド内でコードを実行する．"Dispatch"はコードをAWTイベントディスパッチスレッド内で実行するようにリクエストする．InvokeWaitのデフォルト値はAutomaticで，InvokeWaitの明示的設定が含まれていない場合，デフォルト動作はInvokeThreadの値に基づく．次の表はInvokeWaitのデフォルトにおける自動動作をまとめたものである．

InvokeThreadオプションとInvokeWaitのデフォルト動作を使うと，BindEvent上の新たなスレッドを使ってWolfram言語の計算の実行をスレッドし，SetPropertyValueを呼び出す際にイベントディスパッチスレッド上のユーザインターフェースイベントをアップデートすることができる．

Wolfram言語はマルチプルスレッドからのリクエストを評価することはできないので，実行がスレッドされている間はボタンを無効にし，別のリクエストがカーネル評価列の中で予想外の結果に導かれることを許したいこともあるだろう．

マルチプルスレッド環境でJavaユーザインターフェースを使うことに関する問題のより詳細に渡る説明はSunのJavaに関する文書を参照されたい．