自前の手続き結合慣例, フレーム管理戦略を設計し, フレーム管理とコンテキ ストスイッチのコードが埋め込まれたアセンブリもしくはアセンブリライクな Cコードを生成するマルチスレッドの実装は多数存在する. 最も単純な管理方 式は, 起動ベースによって, 起動時に実行フレームを一般自由記憶(例えばフ リーリスト)から確保する. よって各スレッドはスタックを持つ必要はな い. すべての実行可能なスレッドはタスクプールに入れられる. スレッド生成 はスレッド制御ブロックを確保するだけである. それはスタックを持つ必要は なく, タスクプールに格納される. スレッドがブロックしたときは, それはタ スクプールから他のスレッドをスケジュールするだけである. TAM [40] およびSML/NJ で実装されているスレッド [14] はこのカテゴリーに属する. TAM は関数やループボディ の各並列起動に対してフリーリストから実行フレームを確保する. SML/NJ の スレッド [14] はcallccプリミティブを使ってスレッ ドを実装している. SML/NJ はすべての実行フレームをヒープから確保するの で [3], callccは単に現在のフレームのポインタ を獲得し, callee-save registerをセーブするだけで実装されている. callccを効率的に使用している SML/NJ のスレッドは, 単純なヒープベース のフレーム管理を非常に効率的に実装している. この戦略は呼びだし慣例だけ でなく, 自前のフレームフォーマットを設計する必要がある. そして, Cで書 かれた過去に蓄積されたライブラリの呼びだしには, スタックスイッチのよう な特別なセットアップ手続きを必要とする. このソフトウェア工学がもつ問題 に加えて, このカテゴリーのスレッドはいくつかの性能について不利な点をも つ. まず一つめに, 一般自由記憶からフレームを確保し, フレームをタスクプー ルにエンキューすることは普通スタックフレームを確保するよりも高コストで あるため, スレッド生成がより高コストであるということ. 二つめには, それ らは普通起動の結果の値をレジスタを通じて渡す機会を持っていないこ と. calleeは一般にいつcallerがスケジュールされるかがわからないので, 結 果の値は常にメモリに書かれる. レジスタは揮発性の記憶なので, 結果の値を レジスタを通じて返すことはスケジューリングの順番にいくつかの仮定を必要 とする. 三番目に, それらはスレッド生成におけるcallee-save registerの利 用を提供していないことがある. 全てのコンテキストはスレッド生成の前に callerによって保存される. これはやはり親スレッドと子スレッドの間にスケ ジューリングの順番が仮定されていないからである.