Re: Thread local storage

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:

[...]

>>>>       Deprecate `scm_mask_ints'.
>>>
>>> Is there any replacement, or is this something that there was never any
>>> reason to expose?  It would be good for the deprecation comment to say a
>>> bit more to justify the deprecation.
>>
>> I didn’t understand the point of this macro, and it’s not documented,
>> which is why the deprecation message doesn’t suggest any replacement.
>
> Well, I was going to suggest that we could add something like this
> sentence to the deprecation message.  However...
>
>> Actually, it seems that it was used as an lvalue to mask block asyncs:
>>
>>   http://google.com/codesearch?q=scm_mask_ints&hl=en&btnG=Search+Code
>
> ... this search makes it clear that there's not really any point in
> doing that, since no evidence of any current application Guile using
> scm_mask_ints.

Indeed.

>> Besides, ‘SCM_I_CURRENT_THREAD’ is *not* part of the API.
>
> True, but I think I'd like the 2.0 NEWS to have an explicit entry saying
> that we have cleaned up API visibility, and listing the removed names.

For symbols, the comparison can be done quite easily with ‘objdump -T’.
For macros, it’s more work.

However, I think we should not worry too much about ‘scm_i_’ things that
were removed, with the exception of commonly used idioms such as
‘scm_i_string_chars ()’.  A detailed list of differences could be
helpful to those who have been shamelessly using internals, though.

Keeping an eye on the exported symbols is something that should be more
easily feasible from 2.0 on since internal symbols are not exported.
For internal macros, the best is to avoid them in public headers, but we
can’t avoid all of them, unless we use separate private header(s).

> (Also note that this commit also removes SCM_STACK_OVERFLOW_P from the
> API.  I guess that was never intended to be part of the API either.)

Right, that’s what I thought.

Thanks,
Ludo’.