D has moved up to number 18!

[Sean Kelly]

Dave wrote:
> Sean Kelly wrote:
>> Dave wrote:
>>> Dejan Lekic wrote:
>>>> Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
>>>> myself, but
>>>> failed! :)
>>>> Yes, that is a very nice thread, with many good ideas which followed.
>>>> In short, the basic idea is to move thread support INTO the language.
>>>> Best regards!
>>>
>>> I'd like to interject that, if more threading support is to be added 
>>> to the language, it may be worthwhile to look into moving away from 
>>> 'native threads' (including pthreads) into something more lightweight 
>>> as the internal basis for D threading. Like the recently posted 
>>> StackThreads library maybe(?). Many other languages (especially 
>>> functional languages) are taking this approach - better performance, 
>>> flexibility and portability.
>>
>> Yes and no.  With the number of processors on average systems 
>> increasing rapidly, there's definitely a place for kernel threads in 
>> today's world.  IMO Solaris handles threading fairly well as it 
>> automatically uses both user threads and kernel threads for the 
>> pthread API based on some system knowledge and influenced by some API 
>> parameters.  I like this better than cooperative user-level 
>> multithreading in most cases because it's easier to use and more 
>> flexible for the platform design, though it isn't quite so lightweight 
>> as mutexes and such must still be used.
> 
> I just had reason to take a look at the Solaris thread stuff the other 
> day. Pretty cool.
> 
> So, I guess the challenge may be to try and provide flexible enough 
> language mods. and (a reference) rt lib/compiler interface to 
> accommodate the best for a given platform?

I think so.  Personally, my main interest with new threading work is to 
provide something that avoids the need for direct of most synchronized 
blocks, thread construction, etc, as this stuff is notoriously difficult 
for even experienced programmers to get right.  In the past I've 
mentioned Herb Sutter's Concur project in relation to this, and there 
has been some discussion of related projects and technology as well. 
Were D to set its sights on concurrent programming I'd much prefer it be 
at this level rather than focusing on the traditional approach. 
However, I think a good interim solution (and to simplify implementing 
library support for this sort of thing) would be to expand the 
traditional interface somewhat, at least to include condvars and perhaps 
try-locks.  This can be done largely in library code (someone posted a 
condvar implementation a while back), but as it affects language 
semantics at least marginally I'd prefer it have some sort of official 
seal of approval.  For Ares I've been fairly careful so far to limit 
most of my changes to what I felt was readily identifiable as library 
code, as I don't want to muddy the waters about what is legal D syntax.


Sean