Is D right for me?

[Denis Koroskin]

On Tue, 12 Oct 2010 16:01:30 +0400, Fawzi Mohamed <fawzi at gmx.ch> wrote:

>
> On 12-ott-10, at 13:04, Denis Koroskin wrote:
>
>> On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 10/11/2010 12:38 PM, Daniel Gibson wrote:
>>>> But parts of phobos are deprecated or will be deprecated and there  
>>>> still
>>>> is no alternative for them.
>>>> That may prevent people from writing "real" projects in D2 (or D at  
>>>> all)
>>>> - who wants to use classes that will be deprecated soon?
>>>> Sure, that old stuff will not be removed and can still be used, but I
>>>> personally feel a bit uncomfortable with using deprecated code.
>>>
>>> Agreed. Maybe this is a good time to sart making a requirements list  
>>> for streams. What are the essential features/feature groups?
>>>
>>> Andrei
>>
>> For me, I/O should be scalable (and thus support async operations) so I  
>> came up with my own implementation.
>> I've tried building it on top of std.concurrency, but it doesn't scale  
>> either. So, once again, I had to implement my own message passing  
>> mechanism. I can implement existing std.concurrency interface on top of  
>> my own one without sacrificing anything, but not vice-versa).	
>
> I very much agree that IO should be scalable.
> In my opinion this is possible if one has a robust framework for smp  
> parallelization.
> This is what I have been working on with blip http://dsource.org/blip .
> The API is fixed, and seem to work correctly in all the cases I tested.  
> It has not been optimized so it still has obvious optimizations, but I  
> wanted to have a bit more of code using it, before thinking about  
> optimization (so that I will be able to catch wrong optimizations with a  
> high probability).
> Indeed I have already a rather large amount of code using it, and had  
> still cases where bugs were *very* rare and difficult to locate.
> Still I already used it for example to build a socket server that uses  
> all available threads efficiently to implement rpc between processes.
> One important thing in my opinion is that idle work should not use  
> resources: waiting for i/o, waiting for events uses basically no cpu.
>
> All this is with D 1.0, and tango (even if I did try to reduce and  
> encapsulate the dependence on tango as much as possible).
> For example when using sockets one does not see the blocking by default  
> (for a webserver one will likely want to add some timeout), and the  
> processor transparently switches to fibers that have work to do.
> The programmer has to just think about tasks and things that can be  
> executed in parallel, if possible, the optimal scheduling and mapping to  
> threads is done automatically.
>
> Fawzi

I'm using a thread pool at this moment, however I was thinking about  
implementing some kind of green threads recently.

In D2, there is a local/shared separation, and OS threads should be able  
switch D local context, i.e. forward access to local variables through  
custom TLS class reference, and swap that reference to reuse same thread  
for many "green threads". Conceptually it is different from Fibers (i.e  
you must return instead of just call yield() at any time), but it is also  
easier to implement and pretty much portable to any platform.

Either way, it needs some language support, because currently TLS  
implemented on compiler level rather than library level. I proposed this  
change in past, but no one responded.