GSoC idea for interprocess library in D

[Arun Chandrasekaran]

On Fri, Mar 22, 2019 at 3:55 AM Seb via Digitalmars-d
<digitalmars-d at 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.