From: Kevin Atkinson (kevin_at_[hidden])
Date: 2003-02-19 11:42:42
On Wed, 19 Feb 2003, William E. Kempf wrote:
First off, just in case you didn't realize it, this message was directed at
one person not the group in general. I cced it to the list. I *hate*
> > Are you, or are you not interested in my Lock Classes. The messages I
> > got from you is that you are only interested in my lock classes if
> I haven't had a chance to really evaluate anything here. You'll have to
> give me some more time.
> > 1) It is reproposed as an extension to the locking mechanism in Boost
> > thread.
> > and/or
> I'd say it would at least have to play nice with Boost.Threads. If *I*
> find the idea interesting, I'd personally lean towards making it part of
> Boost.Threads. But technically that wouldn't be an absolute requirement
> for it being considered by Boost at large (even if I'd suspect you'd find
> many people interested only if it were part of Boost.Threads).
Well as I said in a previous email my Lock Classes can be used on top
of any locking mechanism. I used POSIX locks since that I what I used in
my project. But by Mutex class can be substituted by any class that
offers a lock() and unlock() methods or the equivalent of them.
> > 2) It is reworked to somehow be an extension of the smart pointer
> > concept, even though it has very little relation to smart pointers.
> I haven't looked at this at all, so I can't comment too much. But there's
> a lot to be said for having a "locking_ptr" concept, which may be why
> people are advocating it here.
Well as I said before, as far as I know, the only type of pointer like
management that will make sense for a Mutex is a scoped_ptr. This
concept is already implemented in Boost.Thread and not very interesting.
> and since we're in a crunch time, like Beman and others have pointed
> out, you'll not get that kind of feedback, pro or con, at this point in
No problem. I will repost latter if I don't get any serious interest now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk