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

[Matthew Dempsky]

Tom Lord <address@hidden> writes:

> That's a trickier issue.  
> 
> It would be good to have 
> 
>    t_scm_error scm_extract_string (t_udstr * answer, [....])
> 
> but not an `scm_string_value' that gives you the _same_ t_udstr used
> by the Scheme string (except in the innards).

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.  Roughly equal to how numbers
has scm_bignum_value and scm_number_to_bignum -- the first is just an
accessor (and assumes you have the right data type), while the latter
does type checking and is the routine the user's actually intended to
use.

(Initially I was thinking of returning a uni_string with an input
encoding value to specify what the output should be -- would it still
be useful in the form of scm_extract_uni_string?)

> The issue is t_udstr is not intended to be a thread-safe or async-safe
> function.   A t_udstr owned by a Scheme object may change size or
> encoding or (data) address at essentially any time.
> 
> With one exception:  This is what scm_lock_string_data and
> scm_lock_string_data2 are for.   Between them and the corresponding
> scm_release_* call, the t_udstr(s) is (are) promised to be stable.

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?

> 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.

These functions aren't used so they aren't an issue.

>     * 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.)

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.)

>     * If the standard I/O functions such as fwrite are not reentrant
>     then the GMP I/O functions using them will not be reentrant
>     either.

The I/O functions aren't used at all.

>     * It's safe for two threads to read from the same GMP variable
>     simultaneously, but it's not safe for one to read while the
>     another might be writing, nor for two threads to write
>     simultaneously. It's not safe for two threads to generate a
>     random number from the same gmp_randstate_t simultaneously,
>     since this involves an update of that variable.

The only time a GMP value is actually modified is in its construction,
so again this is safe.

>     * 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.)

-jivera