Re: RFC 146 (v1) Remove socket functions from core

[Dan Sugalski]

At 06:27 AM 8/25/00 -0700, Benjamin Stuhl wrote:
> > At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
> > >Dan Sugalski writes:
> > > > One of the current plans is for the parser to have
> > access to a list of
> > > > functions that trigger autoloading modules.
> > >
> > >Isn't dynamic loading really slow?
> >
> > Not particularly, at least not as far as I know. There's
> > some extra cost in
> > finding the library and loading it that you wouldn't pay
> > if you were linked
> > directly to it, but AFAIK that's about it.
> >
> >                                       Dan
>
>There's also the issue that _each_ symbol must be requested
>manually and stored somewhere (in a MT-safe manner, of
>course), rather than having the loader resolve everything
>in one pass.

Far, *far* too much work. We request one function from the library, which 
is some bootstrap code that handles installing the pseudo-op functions in 
that library into a vector table somehwere, and we make sure that darned 
near everything we need to know about the library's built for us in advance.

This scheme may ultimately not be worth it for things like the math 
functions, and that's fine. It doesn't, however, need to be particularly 
expensive.

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk