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

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-10 13:25:18

Pavel Vozenilek(e)k dio:
> "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.

How will you call to a class that just does what
boost::shmem::shared_memory does? It's a wrapper around the OS that just
allocates a shared memory segment. Perhaps, for named_shared_yyy we can
use something like shared_memory_xxx / mmapped_file_xxx /
heap_memory_xxx /user_buffer_xxx. The problem is to find the xxx part.

> To "resist" means finding an use case where
> such pointer is necessary.

A case where you want to byte the whole segment using a char pointer
placed in the segment. The pointer can access the whole segment since.

> 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.

This supposes that only one application creates a segment. And that 
might not be true.

>  __________________________________________________________
>>> 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)

Maybe "beyond shared memory" is a bit pretentious. I will think an 
alternative.

> Good old way:
> 
> #ifdef WINDOWS
>   void shmem_create(....., LPSECURITY_ATTRIBUTES* security);
> #else
>   void shmem_create(....., int security);
> #endif

But can you have a common security attribute set accross win/unix? I'm
not taking about compilation but semantics.

> 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.

You need to see if synchronization objects can be safely copied,
changed and after that crushed with a char buffer. For user objects
fully constructed in shared memory (without external dependencies from 
objects from outside the segment or OS resources) that can be true, but 
with resources from the operating system... who knows.

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

Thanks.

Ion