Re: [boost] [Review] Shmem (lomg)

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-02-09 19:40:57

"Ion Gaztañaga" wrote:

>>    Currently used names are hard
>>    to understand and remember and lack
>>    intuitive meaning.
>>
>>    Some words like "shared", "named"
>>    or "object" are overused
>
> They are not my favorite but I couldn't find better ones! I want also to
> be a relationship between the front-ends, since all offer similar
> functions but each ones operates in a different type of memory
> (named_shared_object, named_mfile_object...). Now we have to find a name
> to an object that creates shared memory/memory mapped file and allows
> allocation of named objects there. I'm open to change it.
>

E.g. "shared_memory" is wasted for some internal
class.

Perhaps this method could be used:

1. select the most important class in the lib
    and assign it the most fitting, short name
    (I suspect named_shared_object -> shared_memory)

2. select the next most important class
     and assign as much fitting name as possible.

3. and so on ...

__________________________________________________________
>> Just a pedagogical nit. The snippets show:
>>
>> int main() {
>>    ...
>>    if (!...) {
>>       return -1;
>>    }
>>
>>
>> Depending on OS the value (-1)
>> would produce strange effects. Use 1.
>
> Strange effects? I didn't know that. Which type of effects? I can change
> all return errors to 1.
>
Some OS may use only lowest 8 bits from the
returned value. It was DOS and possibly Windows.

 __________________________________________________________
>> 4. offset_ptr.html:the "offset_1_null_ptr" policy
>>    is sufficient for all purposes.
>>
>>    Since I cannot think of any use case where
>>    an other pointer policy is required I recommend
>>    to remove them. This should decrease code
>>    complexity and most importantly mental load
>>    on the user.
>
> I know you were since the beginning against this. But I will try once
> more to resist. ;-)
>
To "resist" means finding an use case where
such pointer is necessary.

 __________________________________________________________
>> If process A crashes in the middle
>> of shmem operation (I expect this
>> to happen during development), will
>> all the mutexes/shared memories/etc
>> be destroyed automaticlalyy after
>> process B is closed?
>
> Good question. The answer is... it depends. I can't guarantee cleanup
> when a process crashes, because I can't register rollback functions in
> C++. In Windows, the shared memory is automatically released by the OS.
> In Unix the file-like interface does not do this. And this is really
> annoying. I haven't found solution for this (yes I could handle all
> signals including SIGSEGV, but I would let UNIX signals unusable). If
> any POSIX expert can help I would appreciate.
>
> This is, in may opinion, the weakest point of the library. The behavior
> of the the shared memory is correct when all goes well. But when a
> process crashes, I can't do anything.
>

Perhaps a tool can be provided to do cleanup in
debug mode:

Name of every created shmem/mutex
etc will be  stored in a file and the file will be
deleted on normal application close.

When application restarts it will try to read the file,
if it finds it it will destroy what is recorded there.

With tmpnam() it should be portable and
safe for all practical purposes.

For debugging this should ensure clean system
every time the application starts.

 __________________________________________________________
>> In second case, could some API be added
>> to destroy any named remnants on explicitly?
>
> I think this is a good idea, so that we can make more robust
> applications. I would need to register in a process-level map (a static
> object perhaps all objects when I create them. However, this
> singleton-like interface can create problems if we create static named
> objects (when we will have a good singleton in C++?)
>
Jason Hise: chaos[at]ezequal.com.
Don't know current state.

 __________________________________________________________
>> 12. beyond_shared_memory.html:
>>
>> This name suggests super-advanced functionality
>> far beyond needs or abilities of anyone.
>
> Any name suggestion?
>
Named allocation in user supplied buffer.

(I like complete sentences.)

The "named allocation" could be perhaps
one of basic key terms. It says what and how (up to point)

 __________________________________________________________
>> 13. streams.html: there could be possibly overlap with
>>     Boost.Iostreams library.
>
> I don't know Boost.Iostream well. Anyway, I think bufferstream and
> vectorstream are very general tools that could replace many scanf/printf
> functions of C++ code alergic to stringstream overhead.
>
I've managed to use it only after a long struggle.
Don't know how J. Turkannis is active these days,
perhaps may be asked.

>> Functions like: how-big-is-the-next-message()
>> or peek() may be added.
>
> Ok. With "peek" you mean copying the message but without extracting from
> the queue?
>
Yes.

 __________________________________________________________
>> 19. future_improvements.html
>>
>> Security attributes - IMHO adding them is
>> almost trivial (I know, I know) and they should
>> be added before the library is thrown to public.
>
> But how will you unify POSIX/Windows security attributes? I hard issue,
> in my opinion.
>
Good old way:

#ifdef WINDOWS
  void shmem_create(....., LPSECURITY_ATTRIBUTES* security);
#else
  void shmem_create(....., int security);
#endif

I would even avoid the defaults so people will be forced
to take look on it.

 __________________________________________________________
>> * primitive "transaction like" functionality
>>   for shmem.
>>
>>   Scenario:
>>    - shmem segment exists
>>    - I do copy (clone) of the shmem data
>>    - many operations with shmem are executed
>>    - something may fail but ability to revert into
>>      well-defined state (in application sense,
>>      not in low level C++ sense) is impossible
>>      at this moment
>>    - then the stored copy of shmem will be written
>>      back into shmem segment, restoring the initial,
>>      well defined state.
>
> Uf. I think this is beyond my knowledge!
>
I think just a function to do copy of shmem memory

shared_ptr<char> shared_memory::close()
{
     shared_ptr<char> result(new char[total_size]);
     memcpy(....);
     return result;
}

No locking/checking/whatever.

If the application screws something up
the shmem memory will be overwritten and
voila, we are back.

------------------------------
I'll try how BCB works ith shmem, possibly during the weekend.

/Pavel