Re: [boost] [Review] Shmem

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2006-02-08 20:02:51

> I agree. The problem is that Boost Thread seems to be in stand-by mode,
> so I don't know if we will have any chance to change the situation.

I think this is an important issue for Boost in general!

>
> > Are there any of the latter?  A table would be quite useful here.  For
> > compilers with a reasonable hope of getting changes fed into the
> Standard
> > Library implementation (e.g. gcc) it might be worthwhile to contact the
> > maintainers about these limitations to see if they can be removed.
>
> I have already commented this with Howard Hinnant and Paolo Carlini from
>   libstdc++ in a private mail. They want to support shared memory
> allocators but the work is not trivial, since raw pointers are
> everywhere. I'm ready to help them.

OK, so users need to live with the shmem containers for a while.  Thats OK.
I think you should state this clearly at some point:

  "No Standard Library implementation currently available supports Shmem
this way"

or words to that effect.

I just wanted to say that if you have "static const int a = 5"  (like
> enum { a = 5 };) declarations that are just constant integral values,
> there is no harm. Each process will read their own copy and since both
> will be the same (supposing they use the same version of the class, of
> course) there is no problem.

Perhaps the last clause of tha sentence should be re-written, or stricken
entirely as it seems not to say much.

Sorry about containers. They are not documented at all, since all are
> standard C++ containers in boost::shmem namespace. The only new
> container family is the Loki AssocVector derived flat_map family. I
> agree that I should document that at least. I don't know if
> documentation for others is needed since they are standard C++
> containers in boost::shmem namespace. But if this is what boosters want,
> I will document them (but it's quite a hard work).

It makes no sense to reproduce Standardese for the classes that simply mimic
Standard Library containers, but I would certainly be interested to see some
documentation for the flat_* containers and related classes.

I will try to write a small paper about multi-segment shared memory
> architecture (I mean allocating new segments when we need more memory)
> and the problems I've found when trying to construct them. But this will
> be after Shmem review ends (and if it's accepted, after I make the
> requested changes).

I look forward to it.

Plane boarding.  Skiing trip is finally here!

--
Caleb Epstein
caleb dot epstein at gmail dot