Re: [Pika-dev] so... string work

[Tom Lord]

    > From: Matthew Dempsky <address@hidden>

    > I was actually intending to provide something like the
    > scm_extract_string you mentioned and just use scm_string_value as an
    > accessor to the data types binary data.  

I think the primary legit use for `scm_string_value' is to implement
`scm_lock_string_data[2]'.


    > Just one question about scm_lock_string_data2 -- what was the
    > rationale behind this?  Is it anything but a wrapper to two
    > scm_lock_string_data calls?

Not much more, no.

In a threaded context, if locking is per-string (rather than say,
locking of all strings -- or locking of all threads generally) then
scm_lock_string_data2 needs to be concerned with deadlock.

The alternative here is to have something like scm_lock_string_data
and scm_lock_string_data_instantly_or_fail and scm_string_lock_order
(a total ordering of string objects) -- and require client code to
manage lock priorities sanely.  It seemed far simpler just to capture
the two common cases of wanting to work on one string or two and hide
the deadlock issues inside of reps/.



    > > Gee, I've been presuming that GMP is thread/async-safe.  Is it?  (If
    > > not, that doesn't change any interfaces -- only implementations,
    > > later, when threading and asyncs are added.)

    > Here's what the GMP manual has to say about thread/async issues (from
    > http://swox.com/gmp/manual/Reentrancy.html):

    > > Reentrancy

    > > GMP is reentrant and thread-safe, with some exceptions:

    > >     * If configured with --enable-alloca=malloc-notreentrant (or
    > >     with --enable-alloca=notreentrant when alloca is not available),
    > >     then naturally GMP is not reentrant.

    > I'll leave you to decide how serious this issue is.

    > >     * mpf_set_default_prec and mpf_init use a global variable for
    > >     the selected precision. mpf_init2 can be used instead.

    > >     * mpz_random and the other old random number functions use a
    > >     global random state and are hence not reentrant. The newer
    > >     random number functions that accept a gmp_randstate_t parameter
    > >     can be used instead.

No problem.

    > >     * mp_set_memory_functions uses global variables to store the
    > >     selected memory allocation functions.

    > >     * If the memory allocation functions set by a call to
    > >     mp_set_memory_functions (or malloc and friends by default) are
    > >     not reentrant, then GMP will not be reentrant either.

    > Again, I'll let you decide the severity, but to give a little bit of
    > background context -- by default, GMP uses libc's malloc and friends
    > routines to handle memory, but it accesses them via function pointers
    > set by mp_set_memory_functions.  Because the normal malloc routines
    > aren't interface compatible with lim_malloc et al, I've skipped over
    > this issue for now.  (Besides, even if I did hack it to use
    > lim_malloc, presently lim_malloc is implemented with libc's malloc
    > anyways.)

Nothing to worry about there.

    > Because gmp rather nicely seperates its library into some core numeric
    > routines (mpn_*) optimized for different platforms and the wrapper
    > functions (mpz_* and mpf_*) that handle memory allocation and more
    > useful routines, maybe a long term goal would be to branch GMP and
    > "port" the routines to hackerlab and stick in alloc_limits somewhere.
    > (I daresay this could be done rather easily and backwards compatibly
    > by just modifying the __mpz_struct to hold an alloc_limits value and
    > then create a new mpz_init_limits function.)

Maybe.   Or just persuade the to add an optional rock to their
allocator calls.


    > >     * On SCO systems the default <ctype.h> macros use per-file
    > >     static variables and may not be reentrant, depending whether the
    > >     compiler optimizes away fetches from them. The GMP text-based
    > >     input functions are affected.

    > I intend to use GMP's input functions to parse text, but haven't
    > implemented it yet so this may be an issue... on the other hand, I
    > don't really care about SCO.  (If I _should_ though, tell me and I'll
    > see what I can do.)

No, ignore that.

-t