Coroutines aneb thready bez threadu

[Martin Mares]

Zdravim,

> A pokud nic takoveho neni (o cemz pochybuju): Bude Linuxu vadit,
> kdyz si v procesu vezmu spravu zasobniku do vlastnich paratu?

   Nevadi (uz jsem to nekolikrat pouzil pro vlastni thready :-)), ale ma
to jeden zasadni problem: neumim to napsat portabilne -- samotne prepnuti
zasobniku musi byt v assembleru plus program predpoklada, ze vi, kterym
smerem zasobnik roste a podobne veci.
 
|  Mozna pouzit starsi verzi linuxovych vlaken, ktere si resi vlakna sami, 
| a nepouzivaji podporu jadra.

   Threadove knihovny nejsou pro coroutiny zrovna dobrym resenim -- uvedomte
si, ze kazdy thread musi mit svuj vlastni zasobnik, coz coroutiny nemusi.
Pokud je coroutin nekolik stovek, je uz rozdil dosti znat.
 
# Docela vhodne pro tento ucel jsou setjmp() a longjmp(). Jediny
# platformne zavisly problem je pak inicializace zasobniku.

   Ne, setjmp() a longjmp() pouzit nejde, jelikoz longjmp() znici vsechny
stavy ulozene po setjmp() prislusnem k tomuto stavu.

   (To mi pripomina, ze jsem pred par dny zrovna premyslel nad tim, jak GCC
presvedcit, aby generovalo kod pro coroutiny :-)) ... pokud clovek nepouziva
alloca() ci ekvivalentni mechanismy, nemel by to byt zase takovy problem -- v
podstate staci zmenit standardni prolog a epilog funkce, aby primo nealokoval
misto na zasobniku a aby misto toho zavolal knihovni funkci, ktera alokuje
misto z haldy a _nezapnout_ -fomit-frame-pointer, cimz by se mely lokalni
promenne adresovat pres %esp, zatimco parametry funkce z minuleho stackframu
pres %ebp. Nezkousel jsem to, ale touto cestou by to mohlo jit [bylo by krasne
zridit switch -fcoroutines, ktery by prepnul na tento mechanismus alokace].)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj na ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Entropy isn't what it used to be."