[Phoenix-pm] greetings
Scott Walters
scott at illogics.org
Tue Jul 27 16:17:06 CDT 2004
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. :)
More information about the Phoenix-pm
mailing list