Re: [boost] [boost thread rework] New version uploaded to Boost Vault

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-01 06:26:41

Matt Hurd schrieb:

>>On 01/09/05, Roland Schwarz <roland.schwarz_at_[hidden]> wrote:
>>    
>>
>>>Matt Hurd schrieb:
>>>      
>>>
<-->8-- snipped -->8-- >

>>I would rather like to see the current interface kept as much as possible.
>>Did anyone yet try to find out how deeply the boost::thread is currently
>>wired into the boost lib?
>>    
>>
>
>Good point.  I'll have a look at where a mutex is currently used.  I
>don't think threads and thread pools are used too much in the libs.
>
>  
>
<-->8-- snipped -->8-- >

>>I am missing TLS from this list.
>>    
>>
>
>Yep.  TLS should be in level 0 I'd think if we can squeeze it in
>without too much effort.  I think some simple thread priority stuff,
>along with a platform specific thread id, can slip in too without much
>ado as well.  These seem to be FAQs.
>  
>
Not sure about this. I think the TLS could very well reside in a 
separate unit. It is
almost orthogonal to threads. Of course there is a minor dependancy, but 
that could
be easily solved by introduction of an at_exit_thread mechanism. (Which 
by the way is
already used under the hoods.)
On the other hand the concept of thread id's can be based on an extended 
version
of TLS. I already submitted a draft of this that can be found in my 
thread alert
submission. So in some sense there might be some dependancy from threads 
upon TLS.

>I'll organise a central point by early next week and start a doc if
>agreed.  I'd prefer something like an open office doc to a wiki.
>Changes can be annotated, filtered back and accepted and re-published
>to the site as a doc and as html.  I'm a bit of a dinosaur w.r.t. to
>this new fangled wiki stuff...
>
>  
>
Fine! But I am not sure if switching to open office will set some 
additional barriers for
others. Why not simply using the infrastucture that is already there?
There is already a wiki installed, and there is also a thread section in it.
Could we give it a try?
Also introducing a new method might only artificially increase the ever 
present unavoidable
entropy. I think we rather should put energy in it to decrease it (at 
least locally ;-)

<-->8-- snipped -->8-- >

>The main part that scares me is the trickiness of the static
>linking win32 issues.
>  
>
I am in a good position to deal with these issues, since it was me who 
contributed
the static linking code parts.

>The linux posix implementation will cover many bases...
>  
>
Given.
But what I see as a first major challenge is how to organize the library 
to split
out the platform dependant parts into unique units.
The current method of #ifdef ' ing is not the very best I think.
Perhaps we should set up a split directory structure instead?

But then I see two extremes:
1) A common header which is the only point where platform specific
subheaders are ifdeffed into play. Building the lib is a separate issue and
possibly could be solved by tweaking the bjam accordingly.

2) A common set of headers that defines the interface only and leave
implementation to the platform files. However this seems prohibitive
since this would forbid for platform specific inline optimizations.

Point 1) is at risk, that interfaces start to diverge and 2) still has the
ugly ifdefs.

Any thoughts?

Regards,
Roland