This is quite correct, and I already had amended csound.h to make a note 
that the self pointer should be compared by value, not address.

I think I will simply allocate the object on the heap and the Csound API 
will inform the user that it must be freed after use. This preserves the 
existing ABI which for me is a priority. The semantics do change. We can 
also add a new function taking a pointer to an existing object to receive 
the value, for greater efficiency.

Regards,
Mike

----- Original Message ----- 
From: "Fons Adriaensen" 
To: 
Sent: Wednesday, June 04, 2008 6:31 PM
Subject: Re: [Cs-dev] An oddity


> On Wed, Jun 04, 2008 at 02:37:26PM -0700, Steven Yi wrote:
>
>> Is pthread_t an object that is used by value or by reference?  If by
>> value (i.e. if pthread_t maps to an int or something like that), then
>> we can just mmalloc size(pthread_t), memcpy, and return the value on
>> the heap.  Any caller using that method can mfree or allow csound to
>> cleanup at end in worst case. Am I off?
>
> No. You are touching on the real nature of this problem.
>
> The pthread_t is never to be interpreted by any non-system user.
> If it is part of an ABI, and you want that ABI to be independent
> of the the actual representation, then you need to abstract it.
>
> If the system interface always uses the type by reference, then
> that abstraction is easy: you just use that pointer, cast to void
> pointer if you want. It means that the system assumes responsability
> for maintaining the value it provided a pointer to.
>
> But that is not the case. What you get from pthread_self() is
> a value, not a pointer. You have to preserve this value, even
> if all you ever provide to the external world is a pointer to
> it. This means that somewhere there has to be some code that
> is responsible for the memory management of such copies. In
> practice this means you have to explicitly maintain an array
> (or whatever data structure you like) of them.
>
> If you just provide a pointer to a static value, then either
> that value will become invalid on the next call that overwrites
> it, and from that point on any owners of a pointer to it will
> read the wrong information, OR you have to impose the rule that
> everyone who gets such a pointer has to dereference it ASAP and
> make a private copy the value it points to.
>
> The latter, apart from being a hack relying on the value being
> valid until it is copied (bad idea), is also an implicit change
> of the ABI, and requires recompilation of all clients if they
> are still expected to work correctly. An ABI is not defined
> only by its data structures, but also by the semantics.
>
> In summary: A pointer to a data value is *not* an abstraction
> of that data value.
>
> Ciao,
>
> -- 
> FA
>
> Laboratorio di Acustica ed Elettroacustica
> Parma, Italia
>
> Lascia la spina, cogli la rosa.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net