Re: Multi-object locks (was Re: RFC 35 / Re: perl6-internals-gc sublist)

2000-08-14 Thread Chaim Frenkel
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Be careful what you ask for from us language designers. If you're not LW> careful, we'll take away your low-level primitives and give you something LW> like Ada's rendezvous model. Okay, give. You obviously think it is bad. (I don't know

Re: Multi-object locks (was Re: RFC 35 / Re: perl6-internals-gc sublist)

2000-08-14 Thread Larry Wall
Dan Sugalski writes: : A language issue. Being able to require multiple locks upon entering a sub, : along with timeouts and retries and such, would be very nice, and something : for the language people. (Which probably means some of us over there, since : I don't know that we have that much th

Re: Multi-object locks (was Re: RFC 35 / Re: perl6-internals-gc sublist)

2000-08-07 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> the user needs a mechanism to handle multi-object locking, or a clean >> method to order his lock aquisition. DS> A language issue. Being able to require multiple locks upon DS> entering a sub, along with timeouts and retries and such, wo

Re: Multi-object locks (was Re: RFC 35 / Re: perl6-internals-gc sublist)

2000-08-07 Thread Dan Sugalski
At 06:15 AM 8/7/00 -0400, Chaim Frenkel wrote: > > "JT" == John Tobey <[EMAIL PROTECTED]> writes: > >JT> SVs are never downgraded, so no one's source and destination are >JT> another's respective destination and source. Maybe the above sequence >JT> isn't exactly right, but if we adhere to st

Multi-object locks (was Re: RFC 35 / Re: perl6-internals-gc sublist)

2000-08-07 Thread Chaim Frenkel
> "JT" == John Tobey <[EMAIL PROTECTED]> writes: JT> SVs are never downgraded, so no one's source and destination are JT> another's respective destination and source. Maybe the above sequence JT> isn't exactly right, but if we adhere to strict rules for lock JT> sequencing, there won't be a