"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