Cliff Woolley wrote: > > On 1 Mar 2001, Jeff Trawick wrote: > > > This will be very useful, especially if the semantics of the list > > operations will enable them to be implemented as lock-free operations > > for certain platforms. > > It's the "lock-free operations" part that I've been stumbling over so far. > If we were just talking prefork, it'd be trivial... but keeping it > thread-safe AND lock-free is quite a challenge. If you could have pools that you guarantee not to share across threads... Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ApacheCon 2001! http://ApacheCon.com/
- Re: some reasons why Apache 2.0 threaded is sl... Jeff Trawick
- Re: some reasons why Apache 2.0 threaded i... Cliff Woolley
- Re: some reasons why Apache 2.0 thread... Rodent of Unusual Size
- Re: some reasons why Apache 2.0 th... Bill Stoddard
- Re: some reasons why Apache 2.0 th... Greg Stein
- Re: some reasons why Apache 2... Jeff Trawick
- Re: some reasons why Apac... Greg Stein
- Re: some reasons why Apac... Jeff Trawick
- Re: some reasons why Apac... Greg Stein
- Re: some reasons why Apac... David Reid
- Re: some reasons why Apache 2.0 thread... Ben Laurie
- Re: some reasons why Apache 2.0 th... Greg Ames
- Re: some reasons why Apache 2.0 threaded is slower ... Jeff Trawick
- Re: some reasons why Apache 2.0 threaded is slower ... Bill Stoddard
- Re: some reasons why Apache 2.0 threaded is slower ... John Thompson
- Re: some reasons why Apache 2.0 threaded is sl... Forest Come-Peace
