|
Boost : |
From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2008-02-01 09:22:12
"vicente.botet" ha escrito:
> Hi Joaquin,
>
> What is the magic number 16384 in the intermodule_holder intantiator
> struct intermodule_holder_class contains the following initialization
> instantiator():
> mutex(interprocess::open_or_create,compute_mutex_name()),
> seg(interprocess::open_or_create,compute_segment_name(),16384),
intermodule_holder<T> creates a shared memory segment which is (intendedly)
unique to the combination (process,T), and it is used to share information on the
static data initialization process among the different dynamic modules in the
program.
16 KB is just a conventional size requested for the memory segment. Actually,
this segment only contains a pointer, but it's necessary that the segment be larger
than merely sizeof(void*) to accommodate object names and other
Boost.Interprocess internal information. Maybe 16KB is a little too much and
we could do with 2 or 4 KB, but I didn't think it was worth being avaricious here.
> Should this be configurable?
I don't think so, since the memory segment, as explained above, only holds data
of fixed size.
> Are the compute_mutex_name and compute_segment_name friendly for debuging?
> I think that we will need here some introspection in order obtain these
> values,or better yet to be able to configure them.
The mutex_name (segment_name is similar) has the form
boost_flyweight_intermodule_holder_mutex_A_C0_C1_C2_C3
where A is the current process ID and C0,...,C3 are numbers obtained from hashing
typeid(T).name(), T being the type in intermodule_holder<T>. The intention is that
this name is unique to the combination (process,T). I don't think it should be
configurable, since it's an internal detail and also because the particular
name chosen is crucial to ensuring that the segment is unique to (process,T)
(we're using a process-wide segment for intraprocess purposes.)
Best,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk