Referring to the last question: Hibernate-D is *not* based on Vibe.d. But I have already been looking into the idea of using Hibernate-D and Vibe.d together. In fact, my recent commits to mysql-native adding support for Phobos sockets was a big part of that.

The main issue is that Vibe.d programs should be using Vibe.d
sockets instead of ordinary sockets (I don't know what would happen if
you don't use Vibe.d sockets. My guess is it just wouldn't happen
asynchronously, but Sonke could answer that better). But Hibernate-D
aims to be usable even without Vibe.d, so it uses Phobos sockets for
MySQL (via a modified fork of an older mysql-native), and for PostgreSQL
and SQLite it just uses the C libs.

I've already converted mysql-native to support both Vibe.d and Phobos sockets, and I've already created a branch of Hibernate-D that makes Hibernate-D use the new official mysql-native and therefore automatically switch to Vibe.d sockets whenever Vibe.d is being used (detected by -version=Have_vibe_d, which is automatically added by DUB is you're using both Vibe.d and DUB). But G^DF*^@CKD*#MMIT I *just now* noticed that commit (and the pull request I could have sworn I made) seems to have completely disappeared without a trace...Shit, I gotta figure out what happened and where the hell it went...

Ugh, anyway, I've been digging through Hibernate-D's source the last
couple days checking out what else might be needed. As long as I get my
magical disappearing commit resurrected, it *looks* to me like the only
other thing that might be needed is to bypass Hibernate-D's built-in
connection pool. Even that might still work as-is (I haven't tried),
but it's not really necessary for Vibe.d users since Vibe.d has its
own fiber-safe connection pool system. But it's pretty easy to
bypass Hibernate-D's connection pool in favor of Vibe.D's
connection pool in user-code without even patching Hibernate-D.

AFAICT so far, it looks like everything else in Hibernate-D should work fine with Vibe.d.

tl;dr:

Hibernate-D does not use Vibe.d, but I have personal interest
in using them together and I've been checking into it. Not sure what
can be done about PostgreSQL and SQLite (I *think* they'll work but
just not asynchronously - not sure what else can/should be done, I'd
have to ask Sonke). But for MySQL, all you *should* need is a patch or
two that I've been working on.

On Mon, 3 Jun 2013 18:11:37 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> Referring to the last question: Hibernate-D is *not* based on Vibe.d. But I have already been looking into the idea of using Hibernate-D and Vibe.d together. In fact, my recent commits to mysql-native adding support for Phobos sockets was a big part of that.
> 
> The main issue is that Vibe.d programs should be using Vibe.d
> sockets instead of ordinary sockets (I don't know what would happen if
> you don't use Vibe.d sockets. My guess is it just wouldn't happen
> asynchronously, but Sonke could answer that better). But Hibernate-D
> aims to be usable even without Vibe.d, so it uses Phobos sockets for
> MySQL (via a modified fork of an older mysql-native), and for
> PostgreSQL and SQLite it just uses the C libs.
> 
> I've already converted mysql-native to support both Vibe.d and Phobos sockets, and I've already created a branch of Hibernate-D that makes Hibernate-D use the new official mysql-native and therefore automatically switch to Vibe.d sockets whenever Vibe.d is being used (detected by -version=Have_vibe_d, which is automatically added by DUB is you're using both Vibe.d and DUB). But G^DF*^@CKD*#MMIT I *just now* noticed that commit (and the pull request I could have sworn I made) seems to have completely disappeared without a trace...Shit, I gotta figure out what happened and where the hell it went...
> 
> Ugh, anyway, I've been digging through Hibernate-D's source the last
> couple days checking out what else might be needed. As long as I get
> my magical disappearing commit resurrected, it *looks* to me like the
> only other thing that might be needed is to bypass Hibernate-D's
> built-in connection pool. Even that might still work as-is (I haven't
> tried), but it's not really necessary for Vibe.d users since Vibe.d
> has its own fiber-safe connection pool system. But it's pretty easy to
> bypass Hibernate-D's connection pool in favor of Vibe.D's
> connection pool in user-code without even patching Hibernate-D.
> 
> AFAICT so far, it looks like everything else in Hibernate-D should work fine with Vibe.d.
> 
> tl;dr:
> 
> Hibernate-D does not use Vibe.d, but I have personal interest
> in using them together and I've been checking into it. Not sure what
> can be done about PostgreSQL and SQLite (I *think* they'll work but
> just not asynchronously - not sure what else can/should be done, I'd
> have to ask Sonke). But for MySQL, all you *should* need is a patch or
> two that I've been working on.
> 

Oh wait, I totally forgot:

DDBC was moved out of HibernateD into a separate project, and *that's* where the "missing" commit was. I was looking for it in the wrong project.

Anyway, here are my branches:

https://github.com/Abscissa/hibernated/commits/misc https://github.com/Abscissa/ddbc/commits/misc

And here's the DDBC pull request to make DDBC (the low-level DB abstraction lib used by Hibernate-D) use the official "Vibe.d- and Phobos-compatible" mysql-native:

https://github.com/buggins/ddbc/pull/1

So all you *should* need (for MySQL anyway) is that pull request (or my
full "misc" branches above), and then bypass Hibernate-D's
connection pool in favor of Vibe.d's by changing this part of your code
from:

SessionFactory factory = new SessionFactoryImpl(mySchema, myDialect,
myDataSource);

to something like:

class MyDataSource : DataSource {
    static mysql.db.MysqlDB vibePool;
    override Connection getConnection() {
        if(!vibePool)
            vibePool = new mysql.db.MysqlDB(/+ connection info +/);

        return vibePool.lockConnection();
    }
}

SessionFactory factory = new SessionFactoryImpl(mySchema, myDialect,
new MyDataSource());

On Monday, 3 June 2013 at 22:11:39 UTC, Nick Sabalausky wrote:
> Referring to the last question: Hibernate-D is *not* based on Vibe.d.
> But I have already been looking into the idea of using Hibernate-D and
> Vibe.d together. In fact, my recent commits to mysql-native adding
> support for Phobos sockets was a big part of that.
>
> The main issue is that Vibe.d programs should be using Vibe.d
> sockets instead of ordinary sockets (I don't know what would happen if
> you don't use Vibe.d sockets. My guess is it just wouldn't happen
> asynchronously, but Sonke could answer that better). But Hibernate-D
> aims to be usable even without Vibe.d, so it uses Phobos sockets for
> MySQL (via a modified fork of an older mysql-native), and for PostgreSQL
> and SQLite it just uses the C libs.
>
> I've already converted mysql-native to support both Vibe.d and Phobos
> sockets, and I've already created a branch of Hibernate-D that makes
> Hibernate-D use the new official mysql-native and therefore
> automatically switch to Vibe.d sockets whenever Vibe.d is being used
> (detected by -version=Have_vibe_d, which is automatically added by DUB
> is you're using both Vibe.d and DUB). But G^DF*^@CKD*#MMIT I *just now*
> noticed that commit (and the pull request I could have sworn I made)
> seems to have completely disappeared without a trace...Shit, I gotta
> figure out what happened and where the hell it went...
>
> Ugh, anyway, I've been digging through Hibernate-D's source the last
> couple days checking out what else might be needed. As long as I get my
> magical disappearing commit resurrected, it *looks* to me like the only
> other thing that might be needed is to bypass Hibernate-D's built-in
> connection pool. Even that might still work as-is (I haven't tried),
> but it's not really necessary for Vibe.d users since Vibe.d has its
> own fiber-safe connection pool system. But it's pretty easy to
> bypass Hibernate-D's connection pool in favor of Vibe.D's
> connection pool in user-code without even patching Hibernate-D.
>
> AFAICT so far, it looks like everything else in Hibernate-D should work
> fine with Vibe.d.
>
> tl;dr:
>
> Hibernate-D does not use Vibe.d, but I have personal interest
> in using them together and I've been checking into it. Not sure what
> can be done about PostgreSQL and SQLite (I *think* they'll work but
> just not asynchronously - not sure what else can/should be done, I'd
> have to ask Sonke). But for MySQL, all you *should* need is a patch or
> two that I've been working on.

Regarding PostgreSQL, keep in mind that it has an async API, which would be handy in building a Vibe-friendly wrapper:

http://www.postgresql.org/docs/devel/static/libpq-async.html

Graham

On Monday, 3 June 2013 at 18:51:45 UTC, Vladimir Panteleev wrote:
> On Monday, 3 June 2013 at 18:07:57 UTC, Diggory wrote:
>> Great talk! Would love to see the improvements to phobos suggested.
>>
>> An idea for the virtual address space problem on 32-bit:
>> - Assuming each stack has a marker page at the end to prevent overflow, by simply exchanging the stack memory with a separate block of memory you can reduce the number of marker pages saving up to one page per fiber
>> - Could use some fast compression method to save a not recently used stack in memory
>> - As a last resort can save stack to a file and read it in again when it is required. Since events are queued the event loop can easily peek ahead in the queue and start loading in a stack early so that it is ready by the time that event gets to the front.
>
> Thanks!
>
> One of the main advantages of fibers over threads is the low overhead for switching - basically you save registers and change ESP. By comparison, switching to another thread requires an OS kernel system call. Copying entire stacks might negate this performance benefit. It's worth noting that it looks like the average stack size will grow for D programs in the future, as the push is made to minimize heap allocations throughout Phobos and use the stack more.

Yes, although it would theoretically be possible to swap the stack by swapping the mappings rather than the memory itself, although I doubt many OSes would support that kind of functionality...

I guess it's not too much to ask to use a 64-bit OS for when 1000s of connections need to be handled!