Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?

[Sönke Ludwig]

Am 07.03.2014 23:29, schrieb Sean Kelly:
> On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
>> On Fri, 2014-03-07 at 16:53 +0000, Sean Kelly wrote:
>> […]
>>> 68K connections is nothing. I'll start getting interested when his
>>> benchmarks are 200K+.  Event-based systems in C can handle millions
>>> of concurrent connections if implemented properly. I'd like to
>>> believe vibe.d can approach this as well.
>>
>> There used to be a 100k problem, i.e maintaining more than 100k active,
>> that means regularly causing traffic, not just being dormant for a few
>> centuries, but so many frameworks can now support that , that it has
>> become a non-metric. I don't know if Spring, JavaEE, can handle this but
>> on the JVM Vert.x certainly, I suspect Node.js can as well. Vert.x is
>> caliming to be able to handle millions of active connections.
>>
>> I suspect it is now at the stage that the OS is the bottle neck not the
>> language of the framework.
>
> I think the biggest issue at very large number of connections is memory
> use. In fact, I don't expect even vibe.d to scale beyond a few hundred K
> if it allocates a fiber per connection. It would have to use a free list
> of fibers and make a top-level read effectively release the current
> fiber into the free list. Scaling at this level in C generally meant
> retaining little to no state per connection basically by necessity.

A free list is already used for fibers actually. Each fiber can be 
reused for any number of "tasks". This is also why `Fiber` as a type 
doesn't occur in the public API, but rather the `Task` struct, which 
internally points to a fiber + a task ID.

But since the memory pages of a fiber's stack are allocated lazily, at 
least on a 64-bit OS, where address space is not an issue, you can 
actually scale to very high numbers with a decent amount of RAM. 
Certainly you don't need to have the amount of RAM that the typical 
dedicated server for such tasks would have.

Having said that, it may be an interesting idea to offer a callback 
based overload of waitForData(), so that you can do something like this:

	listenTCP(port, &onConnection);

	void onConnection(TCPConnection conn)
	{
		conn.waitForData(&onData);
		// return (exits the task and puts the fiber
		// into the free list)
	}

	void onData(TCPConnection conn)
	{
		// onData gets called as a new task, so that no fiber is
		// occupied between the wait and the read calls
		conn.read(...);
	}