Csound Csound-dev Csound-tekno Search About

Re: [Cs-dev] An oddity

Date2008-06-04 19:57
FromMichael Gogins
SubjectRe: [Cs-dev] An oddity
To summarize the earlier posts in this thread:

The Csound threading API was written to encapsulate various threading libraries, Windows threads and POSIX threads at least. When it was written, we used native Windows threads on Windows, and all objects were 32 bit handles. Now, to simplify things, we are switching to use POSIX threads on Windows also.

On Windows, pthread_t is a structure containing a 32 bit handle and a 32 bit reference count. That is why we are having this discussion.

All the other pthread header types are 32 bit handles only.

For obvious reasons of backward compatibility, we should avoid changing the Csound threading API unless that becomes impossible. It's not impossible yet, even if we have to work around this silly 64 bit structure.

I am considering a number of possibilities: passing in the pthread_t object to be filled in, malloc'ing the object and returning a pointer that must later be freed, or keeping a table of Csound thread objects around.

Regards,
Mike

-----Original Message-----
>From: Fons Adriaensen 
>Sent: Jun 4, 2008 12:40 PM
>To: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] An oddity
>
>On Wed, Jun 04, 2008 at 12:01:34PM -0400, Michael Gogins wrote:
>
>> I understand what you are saying, but in this context it is better
>> to return the address of a static variable than to change the whole
>> API signature. 
>
>Which means that 'sometimes' it just won't work.
>
>> pthread_t can be type cast to void * on all platforms but Windows.
>> All the other Csound threading API calls use void * for various
>> pthread handles. The only pthread handle that is not still a pointer
>> on Windows is pthread_t. The only problem caused by pthread_t not
>> being a pointer is in this one single function; in all other cases
>> the pointer contains an address to the original pthread_t object
>> created on the heap.
>
>What I don't grok is why it should *ever* be necessary to cast
>a pthread_t to anything else. Just use pthread_t wherever it
>occurs... 
>
>If thread IDs are visible in the orchestra or score language
>(don't know if this is the case), then they should be abstracted.
>In that case keep an array of pthread_t and let the user see 
>only the index.
>
>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

Date2008-06-04 21:10
FromFons Adriaensen
SubjectRe: [Cs-dev] An oddity
AttachmentsNone  

Date2008-06-04 21:26
FromFelipe Sateler
SubjectRe: [Cs-dev] An oddity
AttachmentsNone  None  None  

Date2008-06-04 21:45
FromFons Adriaensen
SubjectRe: [Cs-dev] An oddity
AttachmentsNone  

Date2008-06-05 03:02
FromFelipe Sateler
SubjectRe: [Cs-dev] An oddity
AttachmentsNone  None  None