In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ? I think an end-user calculation is usually one in which he says that a certain lock needs to be acquired in so many seconds ( or milliseconds ) and a boost::posix_time::time_duration would fit that calculation better.
on Mon Dec 26 2011, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ?
Consistency with the C++11 standard threading would dictate providing both interfaces (but using chrono instead of posix_time I think) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/27/2011 12:45 PM, Dave Abrahams wrote:
on Mon Dec 26 2011, Edward Diener<eldiener-AT-tropicsoft.com> wrote:
In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ?
Consistency with the C++11 standard threading would dictate providing both interfaces (but using chrono instead of posix_time I think)
Hopefully the interprocess author will consider it. I will file a suggestion on Trac.
El 28/12/2011 1:25, Edward Diener escribió:
On 12/27/2011 12:45 PM, Dave Abrahams wrote:
on Mon Dec 26 2011, Edward Diener<eldiener-AT-tropicsoft.com> wrote:
In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ?
Consistency with the C++11 standard threading would dictate providing both interfaces (but using chrono instead of posix_time I think)
Yes, there is a plan to update to C++11 interface when some other issues with other libraries (container, intrusive, mainly) are also updated to C++11 changes (allocator_traits, pointer_traits, initializer_lists...).
Hopefully the interprocess author will consider it. I will file a suggestion on Trac.
Yes, please. I think there is a similar ticket, but maybe you can add more detail: https://svn.boost.org/trac/boost/ticket/6218 Ion
2011/12/29 Ion Gaztañaga <igaztanaga@gmail.com>:
Consistency with the C++11 standard threading would dictate providing both interfaces (but using chrono instead of posix_time I think)
Yes, there is a plan to update to C++11 interface when some other issues with other libraries (container, intrusive, mainly) are also updated to C++11 changes (allocator_traits, pointer_traits, initializer_lists...).
What's the reason to wait? Olaf
El 29/12/2011 12:24, Olaf van der Spek escribió:
2011/12/29 Ion Gaztañaga<igaztanaga@gmail.com>:
Consistency with the C++11 standard threading would dictate providing both interfaces (but using chrono instead of posix_time I think)
Yes, there is a plan to update to C++11 interface when some other issues with other libraries (container, intrusive, mainly) are also updated to C++11 changes (allocator_traits, pointer_traits, initializer_lists...).
What's the reason to wait?
A day has only 24 hours ;-) Ion
participants (4)
-
Dave Abrahams -
Edward Diener -
Ion Gaztañaga -
Olaf van der Spek