Fwd: Boost 1.38.0 Interprocess - Question on remove
Hi! I'm using the Boost 1.38.0 Interprocess Library and shared memory object. My code eliminates with a remove a shared memory object associated with a label, the returned value is true so the operation is done correctly; just after that I create a shared memory with the same label and the program throws an error saying "File exists", just as I didn't remove it with the previous instruction. I've seen that the made a bug fix in boost 1.39.0 Interprocess Library on the remove; that fixing reagard this problem or is something different? Do you have an idea of what can be the problem? Thank you, Federico
Federico Golfrè Andreasi escribió:
Hi!
I'm using the Boost 1.38.0 Interprocess Library and shared memory object.
My code eliminates with a remove a shared memory object associated with a label, the returned value is true so the operation is done correctly; just after that I create a shared memory with the same label and the program throws an error saying "File exists", just as I didn't remove it with the previous instruction.
I've seen that the made a bug fix in boost 1.39.0 Interprocess Library on the remove; that fixing reagard this problem or is something different? Do you have an idea of what can be the problem?
I don't have enough data to tell you anything sure. 1.39 affects windows only. With 1.39 windows gets the same behavior as UNIX: you can remove in-use shared memory. Current SVN also has a fix for UNIX remove because the return value was not correct. Best, Ion
Ok, talking about boost 1.38, when the shared_memory_object::remove returns true it was not able to remove the shared memory, right? So that is the reason. This error happens only when running the code on some machines, how can I detect why it was not able to remove a shared memory object? Thank you, Federico 2009/7/3 Ion Gaztañaga <igaztanaga@gmail.com>
Federico Golfrè Andreasi escribió:
Hi!
I'm using the Boost 1.38.0 Interprocess Library and shared memory object.
My code eliminates with a remove a shared memory object associated with a label, the returned value is true so the operation is done correctly; just after that I create a shared memory with the same label and the program throws an error saying "File exists", just as I didn't remove it with the previous instruction.
I've seen that the made a bug fix in boost 1.39.0 Interprocess Library on the remove; that fixing reagard this problem or is something different? Do you have an idea of what can be the problem?
I don't have enough data to tell you anything sure. 1.39 affects windows only. With 1.39 windows gets the same behavior as UNIX: you can remove in-use shared memory. Current SVN also has a fix for UNIX remove because the return value was not correct.
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Can the problem be related with the characters used in the shared memory label? There are some characters that should be avoided? Thank you, Federico Il giorno 03 Luglio 2009 11.32, Federico Golfrè Andreasi < federico.golfre@gmail.com> ha scritto:
Ok,
talking about boost 1.38, when the shared_memory_object::remove returns true it was not able to remove the shared memory, right?
So that is the reason. This error happens only when running the code on some machines, how can I detect why it was not able to remove a shared memory object?
Thank you, Federico
2009/7/3 Ion Gaztañaga <igaztanaga@gmail.com>
Federico Golfrè Andreasi escribió:
Hi!
I'm using the Boost 1.38.0 Interprocess Library and shared memory object.
My code eliminates with a remove a shared memory object associated with a label, the returned value is true so the operation is done correctly; just after that I create a shared memory with the same label and the program throws an error saying "File exists", just as I didn't remove it with the previous instruction.
I've seen that the made a bug fix in boost 1.39.0 Interprocess Library on the remove; that fixing reagard this problem or is something different? Do you have an idea of what can be the problem?
I don't have enough data to tell you anything sure. 1.39 affects windows only. With 1.39 windows gets the same behavior as UNIX: you can remove in-use shared memory. Current SVN also has a fix for UNIX remove because the return value was not correct.
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Federico Golfrè Andreasi escribió:
Can the problem be related with the characters used in the shared memory label? There are some characters that should be avoided?
Thank you, Federico
I don't know, that behaviour is OS dependent, just like file names. Best, Ion
participants (2)
-
Federico Golfrè Andreasi -
Ion Gaztañaga