[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread local storage

From: Neil Jerram
Subject: Re: Thread local storage
Date: Wed, 07 Oct 2009 21:49:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Right, it increases the configuration space, and in practice most people
> will end up using ‘__thread’.  OTOH I think the change is quite
> isolated, since we have only one thread-local variable.

Yes, I agree.

>> Also I wonder, if #1 is always better than the
>> current implementation of pthread_getspecific, why the implementation of
>> pthread_getspecific isn't rewritten so that it uses #1 inside.  Maybe
>> the signature of the pthread_getspecific API doesn't allow that.
> pthread_getspecific(3) is a function, whereas ‘__thread’ requires
> support from the compiler and dynamic linker.


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

... this search makes it clear that there's not really any point in
doing that, since no evidence of any current application Guile using

> In that case, I don’t know how we could provide a useful compatibility
> layer.
> Should we worry?

Given the above, no.

>> This is great.  I recommend writing the NEWS soon too, so as not to
>> build up a backlog of such items that have been removed from the API.
> Well, Andy has been very good at it so far.  ;-)
> 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.

I have in mind to try to produce this myself before 2.0, using some
systematic comparison of the headers and libraries, but it would help if
we all start noting (i.e. in NEWS) removed names (and which we are sure
_should_ be removed) as we go along, so as to reduce the task later of
checking the removals that aren't already listed.

What do you think?

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]