Matt Hurd schrieb:
On 01/09/05, Roland Schwarz <roland.schwarz@chello.at> 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