> enrico franchi wrote: >> In realta' il comportamento che descrivi e' l'implementazione della >> versione principale di go. Nella specifica, non dice niente su M -> >> N. Dice solo che viene chiamata "as an independent concurrent thread >> of control". > > Grazie, m'era sfuggito. > > >> E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1 >> sui thread dell'OS. > > Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(
Solo nella primissima incarnazione. Gia' nel 4.8 si usava makecontext()/swapcontext(), con l'aggravante che ogni volta che veniva fatta una chiamata a una libreria C veniva generato un pthread (ma questo succedeva anche con le prime versioni di go, proprio per evitare casini con lo stack). Nel 4.9 sono stati introdotti gli split stack (feature belissima, che gia' ho avuto occasione di usare in altri contesti) il che ha avvicinato le goroutine di gccgo a go. Inoltre il runtime di gccgo si embedda (anche se in modo rocambolesco, vedere mio post di qualche giorno fa) in ambienti c/c++/obj-c quindi e' un bel vantaggio. E purtroppo (mi tocca dirlo) l'unico di gccgo :( -- Roberto De Ioris http://unbit.com _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
