On Sat, Mar 18, 2006 at 11:01:34PM -0800, Allison Randal wrote: : But, yes, I agree with the principle of not maintaining two : completely separate implementations for synchronous and asynchronous : ops. The earlier design approached that by having the synchronous ops : be asynchronous internally, but my draft suggests this be handled by : having the asynchronous ops use the synchronous ops internally.
Having written one of the latter during my tenure at JPL, I can personally attest that writing async on top of sync is the pits when you're also trying to emulate multithreading, since a "yield" means you end up with arbitrarily deep recursion. Maybe the situation won't arise here with proper stack-switching semantics, but I'm not sure all the architectures you might want to port Parrot to will support threads natively. That being said, if you do port to such an limited architecture, you might end up emulating sync on top of async on top of sync, so the argument runs both ways. I used to think that progress would eventually guarantee that all machines support "modern" semantics, but PDAs kind of disproved that notion, and I think we will always be inventing limited machines at the low end of the size scale. It is unlikely that the first nano-bots will run Linux... I don't really have much wisdom on all of this. But hey, that's why I'm letting other people design the threading, so they can take the blame. :-) Larry
