Re: Cothreads [was Re: Coroutines]
Quoting Michael Lazzaro <[EMAIL PROTECTED]>:
> Similarly, then, I would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread. C would temporarily suspend
> the thread, and C would end the thread. (Note that you could
> use &_.yield to yield the current Code object, so you can have nested
> yields w/out confusion -- see C, from A6.)
On the other hand, with this setup, the user may not be aware that calling foo()
starts another thread; the syntax should, IMHO, be more explicit.
--
"In Soviet Russia, jokes laugh at YOU!"
http://www.milkbone.org
Re: Cothreads
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote: > If we could think about "threads" not in terms of forkyness, but simply > in terms of coroutines that can be called in parallel, it should be > possible to create an implementation of "threading" that had to do a > whole heck-of-a-lot less duplication of state, etc. Things "outside" > the scope of the thread group would automatically be shared(?), things > "inside" the thread group would not be shared unless explicitly marked > as such. > > Which, if I read it right, is what you proposed too, but with a > slightly different syntax. > > That _might_ make threads a heck of a lot faster upon creation/startup, > and a lot less bulky in general. But underneath, these pretty coroutiney/virtual-threads still have to to be implemented in terms of the underlying OS's real threads, so parrot will have to start being really clever applying locks and mutexes all over the place to all those outer bits that are shared etc. So while you may get a cleaner high-level interface to threading behaviour, I don't think you're gonna gain speed and or bulkiness. But I could be wrong. Stranger things have been known :-) -- Blaming Islam for 911 is like blaming Christianity for Oklahoma City.
Compile-time binding
I was reading about Haskell, and realized that I don't know what ::= is supposed to mean (don't ask what that has to do with Haskell :-). I know it's compile-time binding, but... what's compile-time binding? Could someone who knows enlighten me, please? Luke
Re: Compile-time binding
On Wed, May 28, 2003 at 04:41:36AM -0600, Luke Palmer wrote: > I was reading about Haskell, and realized that I don't know what ::= > is supposed to mean (don't ask what that has to do with Haskell :-). > I know it's compile-time binding, but... what's compile-time binding? > > Could someone who knows enlighten me, please? > > Luke Well, perhaps I'm mistaken, but I had understood it to mean simply that the binding between variables and/or methods is established at compile time, not at runtime. Specifically: - Named variables have their addresses hardcoded during compilation - Global variables given offset from start of global data area - Local variables given offset from top of stack - Object variables given offset from start of object data - Normal function and method calls are hardcoded during compilation - Normal functions have specific starting address in object file - Object methods have specific starting address in object file - Compiler is able to determine which function matches each call (The above shamelessly cribbed from: http://www.cs.sbcc.net/~shouk/polyhi/tsld005.htm, because it's 9:34 AM and my brain doesn't wake up for at least another half hour.) -Dks
