Am 21.09.2014 23:45, schrieb Ola Fosheim Grostad:
> On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
>> ...
>>
>> ??? 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.

Since when Go is a competitor in the webspace?

From all the languages used to develop web applications, Go is not on top list for most people.

At least on the IT world I am part of.

--
Paulo

On Sunday, 21 September 2014 at 22:58:59 UTC, Paulo Pinto wrote:
> Since when Go is a competitor in the webspace?

Since people who create high throughput servers started using it?

Am 22.09.2014 01:06, schrieb Ola Fosheim Grostad:
> On Sunday, 21 September 2014 at 22:58:59 UTC, Paulo Pinto wrote:
>> Since when Go is a competitor in the webspace?
>
> Since people who create high throughput servers started using it?
>

Which people? A few Silicon Valley startups, besides Google?

Around me I see such servers being written in Erlang, JVM and .NET languages, with the occasional drop to C++ when nothing else goes.

--
Paulo

On Sunday, 21 September 2014 at 23:28:31 UTC, Paulo Pinto wrote:
> Am 22.09.2014 01:06, schrieb Ola Fosheim Grostad:
>> On Sunday, 21 September 2014 at 22:58:59 UTC, Paulo Pinto wrote:
>>> Since when Go is a competitor in the webspace?
>>
>> Since people who create high throughput servers started using it?
>>
>
> Which people? A few Silicon Valley startups, besides Google?

I am not keeping track, but e.g. https://www.cloudflare.com/railgun

>
> Around me I see such servers being written in Erlang,

Erlang would be another example.

On Sunday, 21 September 2014 at 23:28:31 UTC, Paulo Pinto wrote:
> Am 22.09.2014 01:06, schrieb Ola Fosheim Grostad:
>> On Sunday, 21 September 2014 at 22:58:59 UTC, Paulo Pinto wrote:
>>> Since when Go is a competitor in the webspace?
>>
>> Since people who create high throughput servers started using it?
>>
>
> Which people? A few Silicon Valley startups, besides Google?

Go fizzled inside google but granted has traction outside of
google. Paulo stop feeding the troll for Petes sake.

On Monday, 22 September 2014 at 02:34:00 UTC, Googler Lurker wrote:
> Go fizzled inside google but granted has traction outside of
> google. Paulo stop feeding the troll for Petes sake.

Don't be such a coward, show your face and publish you real name. Your style and choice of words reminds me of A.A. Do the man a favour and clear up this source for confusion.

Locking fibers to threads will cost you more than using threadsafe features. One 300ms request can then starve waiting fibers even if you have 7 free threads. That's bad for latency, because then all fibers on that thread will get 300+ms in latency.

How anyone can disagree with this is beyond me.

On Sunday, 21 September 2014 at 21:42:03 UTC, Ola Fosheim Grostad wrote:
> 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.

Isolated data is single-threaded w.r.t. concurrent access. What thread-safety do you miss? You should only check for environmental dependencies, which are not strictly related to concurrency.

On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
> http://dpaste.dzfl.pl/817283c163f5

You implementation seems to hold water at least in my tests and save memory at

https://github.com/nordlow/justd/blob/master/conceptnet5.d

Thanks :)

I'm however struggling with fast serialization with msgpack. FYI:

https://github.com/msgpack/msgpack-d/issues/43

22-Sep-2014 01:45, Ola Fosheim Grostad пишет:
> 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.

E-hm Go is hardly the top dog in the web space. Java and JVM crowd like (Scala etc.) are apparently very sexy (and performant) in the web space.
They try to sell it as if it was all the rage though.

IMO Go is hardly an interesting opponent to compete against. In pretty much any use case I see Go is somewhere down to 4-th+ place to look at.

>
> Go checks and extends stacks.

Since 1.2 or 1.3 i.e. relatively new stuff.

-- 
Dmitry Olshansky

22-Sep-2014 13:45, Ola Fosheim Grostad пишет:
> Locking fibers to threads will cost you more than using threadsafe
> features. One 300ms request can then starve waiting fibers even if you
> have 7 free threads.

This statement doesn't make any sense taken in isolation. It lacks way too much context to be informative. For instance, "locking a thread for 300ms" is easily averted if all I/O and blocking sys-call are managed in a separate thread pool (that may grow far beyond fiber-scheduled "web" thread pool).

And if "locked" means CPU-bound locked, then it's
a) hard to fix without help from OS: re-scheduling a fiber without explicit yield ain't possible (it's cooperative, preemption is in the domain of OS).

Something like Windows User-Mode Scheduling is required or user-mode threads a-la FreeBSD (haven't checked in a while?).

b) If CPU-bound is happening more often then once in a while, then fibers are poor fit anyway - threads (and pools of 'em) do exactly what's needed in this case by being natively preemptive and well suited for running multiple CPU intensive tasks.

> That's bad for latency, because then all fibers on
> that thread will get 300+ms in latency.

E-hm locking threads to fibers and arbitrary latency figures have very little to do with each other. The nature of that latency is extremely important.

>
> How anyone can disagree with this is beyond me.

IMHO poorly formed problem statements are not going to prove your point. Pardon me making a personal statement, but for instance showing how Go avoids your problem and clearly specifying the exact conditions that cause it would go a long way to demonstrated whatever you wanted to.

-- 
Dmitry Olshansky