> From: Sander Striker [mailto:[EMAIL PROTECTED] > Sent: 11 December 2001 11:27 > > From: Christian Gross [mailto:[EMAIL PROTECTED] > > Sent: 11 December 2001 11:19 > > > At 22:12 04/12/2001 -0500, Cliff Woolley wrote: > > > > > > This is my second go at the pools code. > > > > > >A potential snag with the thread-specific pools idea was brought up today > > >when I was talking with FirstBill and some of the others. What is this > > >going to do to us a little ways down the road when we try to implement > > >async I/O, and all of the sudden requests are jumping from one thread to > > >another? Sounds like a big problem if thread-specific pools are in > > >place... is there an easy answer? > > > > > >--Cliff > > > > Hi > > > > I know I am harping in a bit late in the conversation... BUT I really > > wanted to add something here. COM started with the same thing. In COM > > there are different threading models, which were created out of the need to > > synchronize access and define ownership. Likewise in Windows GUI code you > > had the same situation. In either case the problem's of having thread > > owned stuff is that things become "quirky". When I mean "quirky", I mean > > gee it worked then, but not now. > > A thread doesn't own any pools nor does it know about specific pools, > the same goes for the other way around. > > The idea is to have to option to optimize for the situation where ^^ the
*sigh* > you _know_ that a pool will only be accessed by one thread at a time. > > The app is in control. If you're not sure if you are using a pool > in more than one thread at a time, don't disable locking for that > pools allocator. > > > So sorry about being a bit late on the topic... > > No prob, > > > Christian Gross Sander
