[interprocess] Just a note of thanks to the developers :)
I Have been working on some COM components in the windows environment that have required communication across processes. The abstractions the interprocess library provides have greatly simplified my life (as have many of the other libs in boost, and i have been negligent in my thanks). Thank you so much! Faisal Vali, MD, MSc Radiation Oncology Loyola p.s. If this is the incorrect forum for showing appreciation, I apologize
Faisal Vali wrote:
I Have been working on some COM components in the windows environment that have required communication across processes. The abstractions the interprocess library provides have greatly simplified my life (as have many of the other libs in boost, and i have been negligent in my thanks). Thank you so much!
Thank you for using Interprocess. Feel free to suggest any improvement Regards, Ion
"Ion Gaztañaga" <igaztanaga@gmail.com> wrote in message news:48C026A8.7000208@gmail.com...
Thank you for using Interprocess. Feel free to suggest any improvement
Well, I was just wondering what was the reason for not including a recursive_named_upgradeable_mutex? thanks, -fas
Faisal Vali wrote:
Well, I was just wondering what was the reason for not including a recursive_named_upgradeable_mutex?
I just didn't see any use case for that. Is there any C++ synchronization library that offers this kind of mutex? Why do you need it?
thanks, -fas
Regards, Ion
"Ion Gaztañaga" <igaztanaga@gmail.com> wrote in message news:48C1AACA.5090305@gmail.com...
Faisal Vali wrote:
Well, I was just wondering what was the reason for not including a recursive_named_upgradeable_mutex?
I just didn't see any use case for that. Is there any C++ synchronization library that offers this kind of mutex? Why do you need it?
I had created wrapper functions for my containers that were synchronized using a named upgradeable mutex and lock guards, and ended up having to call one function from the other (which causes deadlock if an exclusive lock is got) - i thought a recursive lock would have allowed this (not sure the pros and cons of this approach). But since there is no such mutex, i settled on a couple of solutions: one involved creating a scoped_lock appropriately if a bool param indicates a lock-recusrive call or not, the other uses templatized versions that use an mpl::if_c to create noop locks if the nontype bool param indicates to do so. Please keep in mind that I am still learning about synchronization issues (and am light on the theory, so i might have missed a common pattern for solving this type of problem) thanks, -fas
On Thu, Sep 4, 2008 at 3:50 PM, Faisal Vali <faisalv@yahoo.com> wrote:
I Have been working on some COM components in the windows environment that have required communication across processes. The abstractions the interprocess library provides have greatly simplified my life (as have many of the other libs in boost, and i have been negligent in my thanks). Thank you so much!
Well said! And not only that you get first class support too. - Rob.
participants (3)
-
Faisal Vali -
Ion Gaztañaga -
Robert Jones