develooper Front page | perl.bootstrap | Postings from July 2000

Re: Threads, reentrancy, and suchlike things (was: Re: WorkingGroup Proposal)

Dan Sugalski
July 24, 2000 08:48
Re: Threads, reentrancy, and suchlike things (was: Re: WorkingGroup Proposal)
Message ID:
At 02:47 PM 7/24/00 +0000, Simon Cozens wrote:
>Dan Sugalski (lists.bootstrap):
> >At 07:56 PM 7/19/00 -0700, Russ Allbery wrote:
> >>Benjamin Stuhl <> writes: >>
> >> > 2 more (neither of which the current parser satisfies):
> >> >    * reentrant, as much as possible
> >>
> >>Thinking about threading and re-entrancy from the very beginning of the
> >>design is *vital*, IMO.
> >
> >Anyone got pointers to papers or publications on these subjects handy?
>I encourage you - nay, I encourage *EVERYONE* - to look at glib.

Are you speaking of glibc here? Assuming you are, there are a few problems:

1) Last time I checked, glibc's license isn't compatible with perl's, and 
I'm really hesitant about using code we can't use as a reference. (It feels 
like stealing, even if it might not be in direct violation of the licensing 

2) Another implementation is just that, an *implementation*. I'm not 
looking for the final product--I'm looking for the theories. Final product 
is nice in some ways, but its already made tradeoffs, and they may not be 
the ones we need to make. They might be, and that's just fine, but I can't 
make a good decision unless I know.

3) I, for one, work better from documentation and theory papers than from 
code. It's a personal quirk

4) glibc seems pretty darned Unix-specific. That's OK for it, certainly, as 
Unix is its target, but we're working with a different problem domain.

>It's got threading. It's got safe signals. It's got hashes. It's got
>arrays. It's got a main event loop with scheduling. It's got safe memory
>allocation. It's got hook functions. It's got IO disciplines. It's got
>platform independent type support. It's got automatic cache support. It's
>got dynamic module loading.
>How many of these wheels are we prepared to reinvent?
>And, more importantly, why?

If the wheel doesn't fit for one reason or another, then we need to 
reinvent it. (And many of these wheels we've already got) Also some of the 
wheels people have invented are... suboptimal.

>Perl has been so amazingly insular to date. CPAN teaches us that code
>reuse is good, and that if some piece of available code doesn't meet our
>needs, we refine it and send back the changes to the maintainer. If we
>base a Perl 6 on libunicode and glib and iconv and whatever, I believe
>we can fix their deficiencies and give the results back to their
>development communities so *everyone* can benefit.

In some ways perl's living in a very different world than most programs, 
and the use of other folk's canned solutions may not be optimal. Perl's a 
language interpreter, and it lives at the same level as glibc and friends, 
and just a half-step up from the kernel.

Chip quoted someone in his Topaz talk (and I don't remember who) "It's not 
that I mind giving up a factor of two in performance, but neither do nine 
of my friends". There's nothing wrong with using library code, but we 
*must* make sure it's as efficient as possible, and it *is* worth us 
rewriting the bits that don't cut it. If libc's IO, for example, was fast 
enough we wouldn't already be bypassing the interface and messing about in 
the guts.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About