November 01, 2012
On Thu, 01 Nov 2012 19:53:37 +0100
"Rob T" <rob@ucora.com> wrote:
> 
> I'm also wondering how the co-routines are working out with vibe? I thought of using them, but my current design will be using message passing instead, where the code is broken up into small parts to perform the co-processing. When messages are received at a location, the code fragment executes. I've done this before in C++ and it worked great, but with D I now have an alternative using fibers, but I have no exerience with using them.
> 

Personally, I think the fibers/coroutines are working out great for it.
The cool thing about the way vibe.d is designed is you really don't
even notice that you're using fibers. It's pretty much all handled
behind-the-scenes. You just give it your callbacks and don't worry
about how they get called. So it feels more like a
simplified message-passing. You rarely deal with the fibers/coroutines
yourself unless you want to.

About the only big thing to be careful of, in my experience, is remembering not to reuse the same open connection (to a DB or other server, for example) across different requests without using the built-in connection pool stuff.

And similarly, you may want to be careful about updating global state (because while globals are *thread*-local by default in D, they're *NOT* fiber-local). But that's a LOT easier to deal with than writing *thread*-safe code with shared state because unlike threads, the fiber switches can only happen in very specific places (when you use vibe.d's async I/O or manually yield the fiber yourself). So just don't do IO or call yield in the middle of an atomic global-state update (or just don't use global state), and you're golden.

November 01, 2012
On 31/10/2012 07:59, Sönke Ludwig wrote:
> Changes:
>
>   - New HTML form interface generator similar to the REST interface
>     generator that simplifies web front end development:
>     http://vibed.org/api/vibe.http.form/registerFormInterface
>     (thanks to Robert Klotzner aka eskimor)
>
>   - Diet HTML templates now support includes and recursive
>     blocks/extensions
>
>   - The REST interface generator has got a new method to reference types
>     in the generated string mixin, which makes it more robust to user
>     defined types (thanks to Mihail Strašun aka mist)
>
>   - Now includes API docs for offline viewing
>
>   - A lot of small fixes and improvements
>
>
> Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9
>
> Download: http://vibed.org/download?file=vibed-0.7.9.zip
>
I have very little server exp and the little I have is from node.js tutorials. I have heard about node.js being used as a game server.
Could vibe.d be used as a multiplayer game server?
And, how (well) does it scale?


November 01, 2012
On Thu, 01 Nov 2012 23:45:17 +0100
Faux Amis <faux@amis.com> wrote:
>
> I have very little server exp and the little I have is from node.js
> tutorials. I have heard about node.js being used as a game server.
> Could vibe.d be used as a multiplayer game server?
> And, how (well) does it scale?
> 

Far better than node.js. Actually, vibe.d is known to scale very well, and it does scale very well in my own tests.

Node.js isn't something I would really recommend for much of anything,
especially a multiplayer game server. No matter how fast its JS engine
is, it's still JS and therefore will *always* be notably slower
than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
1* can run Quake 2).

Plus node.js's design is awkward to use (ie, it's async I/O is very awkward compared to the way Vibe.d handles it, and it's EASY to end up holding up the entire server just because of one slow request). Plus IMO JS is just not a nice language to deal with in the first place. People use JS on the client because it's the only real choice. The server side other options.

If you're not scared off of node.js yet, read this: https://semitwist.com/mirror/node-js-is-cancer.html  (The original link is dead, so I have it mirrored there, minus the CSS so it looks ugly, sorry.)

Coincidentally, I actually *am* writing a multiplayer game server with vibe.d right now (unfortunately I'm not sure I can open source it though, it's for work, and it's relatively game-specific). I'm convinced it's a great way to go, and I haven't come across any big problems. I had stared out with Python at "the boss's" request, but it was a disaster (at least partially b/c of learning curve though: I'm experienced in D, not so much in Python).

November 02, 2012
On 2012-11-01 21:29, Rob T wrote:

> I understand what you are saying, however I was told that you can still
> use shared libs in a limited way. The tricky part is knowing what will
> work and what will not, and why.
>
> I'm used to coding apps that use shared libs, and loadable plugins are
> rather essential to have for some apps, so this is an area of interest
> that maybe I can work on resolving down the road. I'm also interested in
> understanding how people are managing without shared libs. It's nice to
> be able to upgrade code by compiling one shared lib and installing it,
> as opposed to rebuilding an entire set of apps that statically link the
> lib.

What's need to be taken care of in general:

* Module infos
* Exception handling tables
* TLS

-- 
/Jacob Carlborg
November 02, 2012
On 2012-11-02 08:19, Jacob Carlborg wrote:

> What's need to be taken care of in general:
>
> * Module infos
> * Exception handling tables
> * TLS
>

A slightly better answer of what one can expect of not working:

* Exceptions (at least crossing application/library boundaries)
* Module (de)constructors and many things related to runtime introspection, i.e. typeid(), TypeInfo and so on
* Thread local variables
* Probably issues with the GC as well

-- 
/Jacob Carlborg
November 02, 2012
On 2012-11-02 00:14, Nick Sabalausky wrote:

> Node.js isn't something I would really recommend for much of anything,
> especially a multiplayer game server. No matter how fast its JS engine
> is, it's still JS and therefore will *always* be notably slower
> than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
> 1* can run Quake 2).

It's JavaScript, don't use it, what more do one need to know :)

-- 
/Jacob Carlborg
November 02, 2012
It could be something like .NET assembly, i.e. everything needed is in .dll/.so itself. Any chance this happens sometimes?
Dňa 1. 11. 2012 20:23 Jacob Carlborg  wrote / napísal(a):
> On 2012-11-01 19:53, Rob T wrote:
>
>> I know that the druntime will not link as-is without a rebuild to enable
>> PIC, so have you found this to be a problem, not using shared libs, or
>> have you rebuilt druntime to allow for it?
>
> It's not enough to just recompile druntime. It's missing functionality
> to allow true dynamic linking (i.e. dlopen).
>

November 02, 2012
Am 01.11.2012 19:53, schrieb Rob T:
> 
> I'm relatively new to D but making good progress with it after a very slow start (it is a very complex language). Some of what I am working on shares similarities with what vibe.d is doing, so I'm very interested in how vibe.d is progressing.
> 
> vibe.d looks like a rather complex project, so I am wondering if you've made use of any shared libs with D (i.e., .so and/or .a compiled for PIC)?
> 
> I know that the druntime will not link as-is without a rebuild to enable PIC, so have you found this to be a problem, not using shared libs, or have you rebuilt druntime to allow for it?

I haven't used shared libs in conjunction with vibe.d, but in a LLVM based compiler project that was compiled as a DLL (where PIC is not required). For OS X I dodged the PIC problems by compiling it as a static library. But TLS required a lot of tweaking on GDC+Win64 and remained very fragile. Before getting to the root of this and fixing it, development priorities shifted and later I left the company. So unfortunately I can't really offer really useful insights here apart from confirming the already known problems.

> 
> I'm also wondering how the co-routines are working out with vibe? I thought of using them, but my current design will be using message passing instead, where the code is broken up into small parts to perform the co-processing. When messages are received at a location, the code fragment executes. I've done this before in C++ and it worked great, but with D I now have an alternative using fibers, but I have no exerience with using them.

They are working out really well and are a great help to concentrate on concepts rather than how to implement them. I'm also using them in a Windows GUI application, where they are mixed with window message processing, and it really helps to simplify some parts there, which were formerly implemented as threads (with error prone locking/lockless data sharing) or as fragmented jobs with an explicit state (complicating the algorithm). Another place

I would like to have/add std.concurrency style message passing on top though, as that sometimes is actually quite convenient and of course it's also a very safe way to handle communication between fibers that are running on different threads - provided that only immutable/shared/unique data is sent, of course.
November 02, 2012
On Friday, 2 November 2012 at 11:27:22 UTC, Sönke Ludwig wrote:
> Am 01.11.2012 19:53, schrieb Rob T:
>
> I would like to have/add std.concurrency style message passing on top
> though, as that sometimes is actually quite convenient and of course
> it's also a very safe way to handle communication between fibers that
> are running on different threads - provided that only
> immutable/shared/unique data is sent, of course.

Thanks for the input!

A huge advantage of the message passing concept is that it can scale up easily to include threads (I suppose fibres too), as well as independent processes on same machine, and to multiple machines across a network.

AFIK you simply cannot get that kind of scaling without message passing.

At this time the std.concurrency module only supports messaging across threads, so this part will need some work. I have enough C++ experience with messaging across nodes, so I'm at least not starting from scratch.

What I don't know yet, is if I should implement concurrency entirely through message passing, or to include co-routines for the execution part. If I do not use co-routines, then the execution units have to be broken up into parts, following the usual event processing model.

I can manage breaking up code into parts well enough, and there may actually be advantages to doing it that way, but I can also see advantages with using co-routines. I'll have to perform tests to see how it will all fit together, but this will take me a while.

--rt

November 02, 2012
On 02/11/2012 00:14, Nick Sabalausky wrote:
> On Thu, 01 Nov 2012 23:45:17 +0100
> Faux Amis <faux@amis.com> wrote:
>>
>> I have very little server exp and the little I have is from node.js
>> tutorials. I have heard about node.js being used as a game server.
>> Could vibe.d be used as a multiplayer game server?
>> And, how (well) does it scale?
>>
>
> Far better than node.js. Actually, vibe.d is known to scale very well,
> and it does scale very well in my own tests.
>
> Node.js isn't something I would really recommend for much of anything,
> especially a multiplayer game server. No matter how fast its JS engine
> is, it's still JS and therefore will *always* be notably slower
> than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
> 1* can run Quake 2).
>
> Plus node.js's design is awkward to use (ie, it's async I/O is very
> awkward compared to the way Vibe.d handles it, and it's EASY to end up
> holding up the entire server just because of one slow request). Plus
> IMO JS is just not a nice language to deal with in the first place.
> People use JS on the client because it's the only real choice. The
> server side other options.
>
> If you're not scared off of node.js yet, read this:
> https://semitwist.com/mirror/node-js-is-cancer.html  (The original
> link is dead, so I have it mirrored there, minus the CSS so it looks
> ugly, sorry.)

I actually read that website when I tried out node.js. I thought vibe.d would suffer the same locking behaviour.