On Saturday, 20 September 2014 at 16:57:49 UTC, Andrei Alexandrescu wrote:
> Thanks!

Calling writeln(rcstring) in a module other than rcstring.d

gives

immutable(RCXString!(immutable(char), 23LU, realloc))(#{overlap large, small, msmall}, '\b', [10280751412894535920, 0, 576460752303423488])

I believe you have to make either opSlice public or add a public toString.

20-Sep-2014 21:55, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" пишет:
> On Saturday, 20 September 2014 at 15:30:55 UTC, Andrei Alexandrescu wrote:
>> I understand. RC strings will work just fine. Compared to interlocked
>> approaches we're looking at a 5x improvement in RC speed for the most
>> part because we can dispense with most interlocking. -- Andrei
>
> Can someone explain why?
>
> Since fibers can travel between threads, they will also be able to leak
> objects to different threads.

Not spontaneously :)
You'd have to cast to shared and back, and then you are on your own.
Fiber is thread-local, shared(Fiber) isn't.

-- 
Dmitry Olshansky

On Sunday, 21 September 2014 at 08:24:46 UTC, Dmitry Olshansky wrote:
> Not spontaneously :)
> You'd have to cast to shared and back, and then you are on your own.
> Fiber is thread-local, shared(Fiber) isn't.

That will have to change if Go is a target. To get full load you need to let fibers move freely between threads I think. Go also check fiber stack size... But maybe Go should not be considered a target.

On 16.09.2014 17:38, Andrei Alexandrescu wrote:
> On 9/15/14, 4:49 PM, Rainer Schuetze wrote:
>>
>>
>> On 15.09.2014 10:24, Andrei Alexandrescu wrote:
>>>>
>>>> Hmm, seems fine when I try it. It feels like a bug in the type system,
>>>> though: when you make a copy of const(RCXString) to some RCXString, it
>>>> removes the const from the referenced RCBuffer struct mbuf!?
>>>
>>> The conversion relies on pure constructors. As I noted in the opening
>>> post, I also think there's something too lax in there. If you have a
>>> reduced example that shows a type system breakage without cast, please
>>> submit.
>>
>> Here's an example:
>>
>> module module2;
>>
>> struct S
>> {
>>      union
>>      {
>>          immutable(char)* iptr;
>>          char* ptr;
>>      }
>> }
>>
>> void main()
>> {
>>      auto s = immutable(S)("hi".ptr);
>>      S t = s;
>>      t.ptr[0] = 'A';
>> }
>>
>> It seems the union is hiding the fact that there are mutable references.
>> Only the first field is verified when copying the struct. Is this by
>> design? (typeof(s.ptr) is "immutable(char*)")
>
> Not sure whether that's a bug or feature :o). In fact I'm not even
> kidding. The "it's a bug" view is obvious. The "it's a feature" view
> goes by the reasoning: if you're using a union, it means you plan to do
> gnarly things with the type system anyway, so the compiler may as well
> tread carefully around you.
>
> Through a rather interesting coincidence, I was talking to Walter during
> the weekend about the idiom:
>
> union
> {
>      immutable T data;
>      T mdata;
> }
>
> which I found useful for things like incrementing the reference counter
> for non-mutable data. I was discussing how it would be cool if the
> compiler recognized the construct and did something interesting about
> it. It seems it already does.
>
>
> Andrei
>

There is already bug report for this: https://issues.dlang.org/show_bug.cgi?id=12885

It also references the issue why this has been changed pretty recently: https://issues.dlang.org/show_bug.cgi?id=11257

I'm on the fence whether this is convenient or makes it too easy to break const "guarantees". It seems strange that you can modify a const-reference only after you make a copy of the "pointer". ATM I'd prefer seeing an explicite cast for that.

On 09/21/2014 11:53 AM, Rainer Schuetze wrote:
>
> It also references the issue why this has been changed pretty recently:
> https://issues.dlang.org/show_bug.cgi?id=11257
>
> I'm on the fence whether this is convenient or makes it too easy to
> break const "guarantees". It seems strange that you can modify a
> const-reference only after you make a copy of the "pointer". ATM I'd
> prefer seeing an explicite cast for that.

This change is unsound.

import std.variant;

void foo(const(Algebraic!(int*,const(int)*)) x)@safe{
    Algebraic!(int*,const(int)*) y=x;
    *y.get!(int*)()=2;
}

void main()@safe{
    auto x=Algebraic!(int*,const(int)*)(new int);
    assert(*x.get!(int*)()==0); // pass
    foo(x); // passed as const, so shouldn't change
    assert(*x.get!(int*)()==2); // pass!
}

On Sunday, 21 September 2014 at 09:06:57 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 21 September 2014 at 08:24:46 UTC, Dmitry Olshansky wrote:
>> Not spontaneously :)
>> You'd have to cast to shared and back, and then you are on your own.
>> Fiber is thread-local, shared(Fiber) isn't.
>
> That will have to change if Go is a target. To get full load you need to let fibers move freely between threads I think. Go also check fiber stack size... But maybe Go should not be considered a target.

It doesn't ring a bell to me. For several reasons:

1) Go doesn't seem to be a target right now. There has been certain examples that D is capable to beat Go in its own domain (see Atila MQTT broker articles). It may change later but there has been no experimental confirmations that their approach is better by design.

2) For good CPU load distribution moving of task is likely to be needed indeed but it is not necessarily the same thing as moving fibers and definitely not all need to be moved. I like that vibe.d goes forward with this by defining own `Task` abstraction on top of fibers. Thus this is something that belong to specific task scheduler/manager and not basic Fiber implementation.

21-Sep-2014 13:06, Ola Fosheim Grostad пишет:
> On Sunday, 21 September 2014 at 08:24:46 UTC, Dmitry Olshansky wrote:
>> Not spontaneously :)
>> You'd have to cast to shared and back, and then you are on your own.
>> Fiber is thread-local, shared(Fiber) isn't.
>
> That will have to change if Go is a target.

Go is not a target. The fixed concurrency model the have is not the silver bullet.

> To get full load you need to
> let fibers move freely between threads I think.

Why? The only thing required is scheduling by passing new work-item (a fiber) to the least loaded thread (or some other strategy). Keeping thread affinity of Fiber is a boon: you get to use non-atomic ref-counting and have far less cache pollution (the set of fibers to switch over is consistent).

> Go also check fiber
> stack size... But maybe Go should not be considered a target.

??? Just reserve more space. Even Go dropped segmented stack.
What Go has to do with this discussion at all BTW?

-- 
Dmitry Olshansky

On Sunday, 21 September 2014 at 09:06:57 UTC, Ola Fosheim Grostad wrote:
> That will have to change if Go is a target. To get full load you need to let fibers move freely between threads I think. Go also check fiber stack size... But maybe Go should not be considered a target.

Only isolated cluster can safely migrate between threads. D has no means to check isolation, you should check it manually, and in addition check if the logic doesn't depend on tls.

On Sunday, 21 September 2014 at 19:28:13 UTC, Kagamin wrote:
> Only isolated cluster can safely migrate between threads. D has no means to check isolation, you should check it manually, and in addition check if the logic doesn't depend on tls.

This can easily be borked if built in RC does not provide threadsafety.

If you want low latency, high throughput and low memory overhead, then you gotta use available threads. Otherwise the load balancing will be wonky.

Most requests in a web service will wait for network traffic from memcaches. So a requeston a fober will have to be rescheduled at least once on average.

On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
> to use non-atomic ref-counting and have far less cache pollution (the set of fibers to switch over is consistent).

Caches are not a big deal when you wait for io.

>> Go also check fiber
>> stack size... But maybe Go should not be considered a target.
>
> ??? Just reserve more space. Even Go dropped segmented stack.
> What Go has to do with this discussion at all BTW?

Because that is what you are competing with in the webspace.

Go checks and extends stacks.