<ArunC> Hello
<alphaglosined> hi hi
<ArunC> I'm not sure if this is the right place to ask about vibe.d, but not sure where else to go.
<ArunC> I'm trying to develop an app in D that exposes RESTful services and at the backend, it would spawn and manage a bunch of processes (workhorses)
<alphaglosined> expensive operation seperate processes but ok
<ArunC> We are predominantly a C++/Java shop and I'm trying to inject D here, just because I think it is a much better alternative.
<alphaglosined> indeed, so where is the problem?
<ArunC> We have these "child" processes listening on ZMQ IPC sockets and working already. There is no problem with that. I am wondering if it is possible for us to expose vibe.d handlers to communicate via ZMQ with the backend processes.
<ArunC> As I read, vibe.d works on fibers and not on explicit threading, whereas ZMQ works on explicit threading (created by zmq contexts)
<alphaglosined> oh I see so you're worried that the fibers won't execute on the proper thread
<alphaglosined> in that case I would use message passing if you don't need to get a response from the backend process
<alphaglosined> with a dedicated thread handling it
<ArunC> Fibers are executed using cooperative IIRC. So if we are to create a context, send and receive (let's assume a simple REQ-REP here) and close the context, I wondering if fibers would go by that.
<ArunC> hmm, I see.
<ArunC> The constraint here is, we can't change the backend processes.
<ArunC> ...unfortunately
<alphaglosined> yeah in your case the problem with fibers is you cannot guarantee the thread for a request handling
<ArunC> I see.
<ArunC> Is there anyway for us to instruct vibe.d to use a concurrency model described by the user? ie, to choose thraeds instead of fibers?
<alphaglosined> no
<alphaglosined> it would also make it significantly slower
<ArunC> Well, there are use cases like this where it makes sense to do that, albeit being slow compared to fibers. But definitely much faster compared to the implementations in other languages (with the benefit of readability), which is why I'm here. :-)
<alphaglosined> maybe vibe.d is the wrong solution then
<ArunC> hmm, any other RESTful frameworks in D?
<alphaglosined> I don't think you need the extra functionality
<alphaglosined> maybe just a CGI interface will be enough
<alphaglosined> https://github.com/adamdruppe/arsd/blob/master/cgi.d
<alphaglosined> adam_d_ruppe
<ArunC> I would definitely need a RESTful frontend with an implicit json support.. something like https://github.com/matt-42/silicon/
<ArunC> Silicon (C++) - it is all macro magic + awful template syntax, a bit like using a language extension.. so I'm a bit hesitant to resort to that solution..
<alphaglosined> because of D's CTFE capabilities, while you won't find any implicit json support
<alphaglosined> but you can always implement it as you need