On Fri, Mar 22, 2019 at 3:55 AM Seb via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 18 March 2019 at 05:19:21 UTC, Arun Chandrasekaran wrote:
> > On Sunday, 17 March 2019 at 12:16:51 UTC, Francesco Mecca wrote:
> >> On Thursday, 14 March 2019 at 06:12:21 UTC, Arun Chandrasekaran wrote:
> >>> On Wednesday, 13 March 2019 at 21:31:44 UTC, Johannes Pfau wrote:
> >>>> [...]
> >>>
> >>> Right, something like that would be good to have. For
> >>> demonstration, I've literally translated one of the C++
> >>> example from here to D -
> >>> https://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue
> >>>
> >>> [...]
> >>
> >> You had a very nice idea, currently one of the best proposed
> >> for this GSOC (until now).
> >> Also we badly need libraries for the HPC space.
> >>
> >
> > Thanks, hope to get the community support for this to be accepted in GSoC.
> >
> >> The example is clear enough but can you provide us examples on how porting this library to D would be better than having proper bindings?
> >
> > AFAIK, D shares the same binary interface with C and not with C++. So I doubt if a binding would benefit D, because the new library under proposal should be able to construct D objects (struct/class) on shared memory. A binding, however, would only instantiate C++ objects on shared memory.
>
> @Arun: did you manage to work a bit more on this?
>
Unfortunately I didn't get time to work on this yet. Work is up to the neck.

> A few questions to get a discussion going:
>
> - do you want to be API-compatible with std.concurrency?

I'm not a student proposing this library. Sorry if I've given that impression.
Boost::interprocess exposes wide variety of APIs and use cases. I
looked at what std.concurrency offers and I'm pretty sure the APIs
can't be compatible.

> - what would be your rough roadmap (in terms of features that you would want to get done during the summer)?

At a high level, it offers the following features:

1. default and custom allocators to operate on shm.
2. named IPC primitives: shm, semaphores, spinlock, mutex, condvar, barriers
3. standard containers like vector, deque, list, string, set that
operates on shm
4. message queue on shm
5. managed shared memory
6. IPC smart pointers

The LOC of boost::interprocess itself is is around 55K (the whole of Boost is around 1.8 million LOC), but I'm not sure how much effort it would take to do this in D.

12:36:05 AIM-ES ~/code/cpp/boost_1_69_0/boost$ cloc container interprocess
     275 text files.
     275 unique files.
       1 file ignored.

github.com/AlDanial/cloc v 1.74  T=0.86 s (319.4 files/s, 103385.2 lines/s)
-------------------------------------------------------------------------------
Language             files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header           274          12863          22574          53241
-------------------------------------------------------------------------------
SUM:                   274          12863          22574          53241
-------------------------------------------------------------------------------
12:36:07 AIM-ES ~/code/cpp/boost_1_69_0/boost$

>
> I guess benchmarking one or two examples in std.concurrency vs. Boost::interprocess for fun could make your point crystal clear.

std.concurrency offers few APIs whereas boost::interprocess is feature rich. I will still try to create an equivalent example sometime next week.

On Fri, Mar 22, 2019 at 4:45 AM Basile B. via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 13 March 2019 at 02:20:39 UTC, Arun Chandrasekaran wrote:
> > Hello,
> >
> > I would like to propose the idea to develop an interprocess library similar to Boost::Interprocess in C++ https://www.boost.org/doc/libs/1_63_0/doc/html/interprocess.html
> >
> > Boost::Interprocess is a very powerful and feature rich library for developing cross platform server and desktop apps.
> >
> > Boost.Interprocess offers:
> > 1. shm based queues without relying on the kernel for data
> > transfer. This is a huge win for low latency apps in the order
> > of micro seconds)
> >
> > 2. shm based object allocation, construction and destruction.
> >
> > Etc
> >
> > Is there an equivalent library in the D ecosystem? What do you people think about the idea?
> >
> > Arun
>
> I like the idea, although from my own experience IPC is quite easy, the real stuff is more the communication process, i.e the protocol, which seems to be message loop for you. I had worked a bit on the easy part [1] and you can count on my help if your

The IPC itself is easy as OS does most of the weightlifting. But designing a stable, easy to use library will definitely be challenging & achieving. I remember the days back when we had to struggle with ACE[1] (respect the author, this was the only library that I was aware of back then). boost::interprocess just made everyone's life easy in a lot of ways.

> submission is accepted, although I say it clearly **this is not a proposal for mentorship**.
>
> [1] : https://github.com/Basile-z/iz/blob/master/import/iz/ipc.d

I'm not a student either.

[1] http://www.dre.vanderbilt.edu/~schmidt/ACE.html