>
> Sönke, vibed is truly amazing! I am interested in the web server's internal
> architecture. I always wanted to do an implementation of a web server using
> a form of asymmetric, multi-process event-driven architecture. A web server
> which utilises fibers. It would be nice if you explain the web-server
> architecture of vibed in more details.
>
> Keep up with good work!
>
> Regards

Thanks! I will add a page with graphical explanation on the website when I have some time. But in short all fibers are currently living in the same thread. Each fiber is registered with one or multiple events inside of the event driver (libevent based currently). As soon as an event arrives, the corresponding fiber is resumed. The fiber will then simply do conceptually this for every blocking operation:

blockingOperation(){
	requestOperation();
	while( !operationFinished() ) yield();
}

I've thought about sharing fibers across threads but came to the conclusion that this is probably more trouble than it's worth. An alternative would be to start multiple event loops in separate threads and then distribute incoming connections to these loops before starting a corresponding fiber.

Right now its at least possible to off-load all computational tasks using std.concurrency or std.parallelism or similar. An efficient asynchronous wait function for a std.concurrency message or for a std.parallelism task would be useful though.

Am 26.04.2012 23:54, schrieb Trass3r:
> Looks promising.
>
> Though I wouldn't know how to choose between Adam's web framework,
> Cybershadow's code (seemed like he coded the newsreader in no time and
> it works very nicely) and yours.
> Any advice?

I guess it just comes down to tast and requirements. If you need high performance in high load situations or if you are used to the router-view-template system (with HAML or Jade templates) vibe should be a good choice.

But although I haven't looked very deep into the other two, I know that at least Adam's code contains a lot of features that are not yet available in vibe or are maybe not planned at all (e.g. the handy DOM manipulations). Of course, since vibe is also usable as a simple library, its also possible to combine parts of each framework.

The server is back up and I've looked at Flask's blueprints. So they have a more implicit approach with annotations (once D has these, it would be a possible extension for vibe). Right now my corresponding pattern looks like this:

// create a global url router
auto r = new UrlRouter

// create application specific routes
r.get("/", &showHomePage);

// let each sub-component register its routes, possibly in a sub-path
registerVibeLog(settings, router);
registerTicker(router, "/ticker");

In _d_throw call abort().  That'll give you a core file.

On Apr 26, 2012, at 11:13 PM, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> Am 27.04.2012 04:19, schrieb Andrei Alexandrescu:
>> On 4/26/12 3:30 PM, Jesse Phillips wrote:
>>> On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:
>>>> On 26/04/2012 21:46, Sönke Ludwig wrote:
>>>>> vibe.d
>>>> 
>>>> This looks awesome!
>>>> 
>>>> Also on reddit: http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/
>>>> 
>>>> 
>>>> 
>>>> and hacker news: https://news.ycombinator.com/item?id=3896197
>>> 
>>> Now look what you did, you killed it.
>> 
>> Are the Vibe people on this? Though the intent is very nice, this is not looking great right now.
>> 
>> Andrei
> 
> 
> It's back up now and I've made a small watchdog script to avoid this in the future.
> 
> The problem is that I'm currently using a vibe based reverse proxy instead of nginx and it rarely has an uncaught exception that unfortunately has never been logged with stack trace. I wish I could have made this part rock solid before going live but someone else annouced it before me so it was too late.

On 27-04-2012 16:50, Sean Kelly wrote:
> In _d_throw call abort().  That'll give you a core file.
>
> On Apr 26, 2012, at 11:13 PM, Sönke Ludwig<sludwig@outerproduct.org>  wrote:
>
>> Am 27.04.2012 04:19, schrieb Andrei Alexandrescu:
>>> On 4/26/12 3:30 PM, Jesse Phillips wrote:
>>>> On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:
>>>>> On 26/04/2012 21:46, Sönke Ludwig wrote:
>>>>>> vibe.d
>>>>>
>>>>> This looks awesome!
>>>>>
>>>>> Also on reddit:
>>>>> http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/
>>>>>
>>>>>
>>>>>
>>>>> and hacker news:
>>>>> https://news.ycombinator.com/item?id=3896197
>>>>
>>>> Now look what you did, you killed it.
>>>
>>> Are the Vibe people on this? Though the intent is very nice, this is not
>>> looking great right now.
>>>
>>> Andrei
>>
>>
>> It's back up now and I've made a small watchdog script to avoid this in the future.
>>
>> The problem is that I'm currently using a vibe based reverse proxy instead of nginx and it rarely has an uncaught exception that unfortunately has never been logged with stack trace. I wish I could have made this part rock solid before going live but someone else annouced it before me so it was too late.

Why don't we make that some kind of function in druntime? like setAbortOnThrow(bool) or whatever.

-- 
- Alex

Sönke Ludwig:

> The "import vibe.d;" is actually just a play on the frameworks name and just should be easy to remember. In addition to importing all modules, it also imports a module containing the main function, so this is a special beast. But there is actually a "import vibe.vibe;" which is the equivalent to the "vibe.all".

But isn't ".all" a kind of standard D convention (that is better to generally use)? (I am not sure).

Bye,
bearophile

On Friday, 27 April 2012 at 15:26:02 UTC, bearophile wrote:
> But isn't ".all" a kind of standard D convention (that is better to generally use)? (I am not sure).

No, not at this point. Some people prefer somepackage._, and there recently has been a proposal by Andrei (DIP16) to allow a special »somepackage.package« module.

David

On Apr 27, 2012, at 1:27 AM, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> 
> We still have a more comprehensive benchmark on the table but it seemed to get along happily with about 60MB of RAM usage during a C10k test. The average request time went down to about 6s if I remember correctly. The test was using a dual-core Atom server over a WiFI connection so the results may have been skewed a litte.

6s?  Not 6ms?  Why so slow?

Am 27.04.2012 18:54, schrieb Sean Kelly:
> On Apr 27, 2012, at 1:27 AM, Sönke Ludwig<sludwig@outerproduct.org>  wrote:
>>
>> We still have a more comprehensive benchmark on the table but it seemed to get along happily with about 60MB of RAM usage during a C10k test. The average request time went down to about 6s if I remember correctly. The test was using a dual-core Atom server over a WiFI connection so the results may have been skewed a litte.
>
> 6s?  Not 6ms?  Why so slow?

With 10000 connections concurrently.. not exactly sure who is reposible but probably either the network or libevent. But some diagnostic benchmarking is in order.

Le 27/04/2012 17:29, David Nadlinger a écrit :
> On Friday, 27 April 2012 at 15:26:02 UTC, bearophile wrote:
>> But isn't ".all" a kind of standard D convention (that is better to
>> generally use)? (I am not sure).
>
> No, not at this point. Some people prefer somepackage._, and there
> recently has been a proposal by Andrei (DIP16) to allow a special
> »somepackage.package« module.
>
> David

Both are very used.