in reply to Re^4: Thread::RWLock for 5.8 threads ?
in thread Thread::RWLock for 5.8 threads ?

And then I need to figure out where/how to CPAN it.

Yep. And there lies another minefield.

You'll see that I chose to use threads::RWLock as a working title.

That would get frowned upon by the "powers that be", because it has a all-lower first element to the name, but quite frankly, continuing to stick threads-related modules in the Thread::* namespace just invites further and continued confusion over what works with what and why. Like Perl's threads need another barrier to use.

But then I guess the "powers-that-be" that makes these stupid decisions are probably all hardcore 'we don't need no stinkin' threads'-people anyway.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^6: Thread::RWLock for 5.8 threads ?
by renodino (Curate) on Oct 24, 2005 at 18:13 UTC
    Yeah, namespace is an issue. In the interest of GOWI, I'll probably bury it inside the Thread::Queue::Duplex bundle. Tho maybe "Thread::Resource::ReadWrite" might be a good namespace, so anything else related to sharing resources among threads has a root. I'm already considering an alternate locking algorithm that permits upgrading read to write locks, or downgrading writes to reads; as currently implemented, T::RWLock requires a reader to unlock before it could get a write lock.
[reply]

In Section Seekers of Perl Wisdom