[Phoenix-pm] greetings

[Scott Walters]

Gimmie September! Sides, depending on which Thursday you mean, I might not
be in town, and a lot of people are breathing down my neck right now. I
wouldn't do a god job. 

-scott

On  0, "Douglas E. Miles" <perlguy at earthlink.net> wrote:
> 
> Scott Walters wrote:
> > I tried a few times but I reeled, licking my wounds, each time. 
> > Threads in Perl are extremely heavy - most things wind up in thread-local-store
> > so you get copy-on-write semantics like fork() but the setup for a new thread is
> > far worse than for fork(). When variables are shared, it's extremely difficult to
> > pass a data structure through it and neigh on impossible to pass a reference to
> > an object that refers to other objects. Unless each array and hash in the datastructure -
> > even anonymous ones - has been created :shared or run through share(), it vanishes
> > without coming out the other side. The other thread never sees it. Objects have
> > the same problem but they also come unblessed. So threads aren't much better than 
> > using fork()ed processes with SysV shared memory and semahores and such. 
> > 
> > I've been fiending on Coro, though (as some of you know). Coro is 
> > non-preemptive, and for variable and datastructure sharing, uses the regular
> > lexical scope rules and reference rules. None of the above problems exist. 
> > They're extremely light to create. Doing I/O concurrently takes a little more
> > work as coroutines don't automatically go to sleep, yield the CPU, and wait for 
> > data to arrive. Instead you must use special classes to wrap IO:: classes
> > or the Event class.
> > 
> > I touched on this briefly in my Perl 6-isms part II presentation but I'd
> > be happy to round it out >=)
> > 
> <SNIP>
> 
> If Brock doesn't take the whole 2 hours, you are welcome to the 
> remainder.  If you need the whole 2 hours, your can have Sept. :)