Re: apache style squid?

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

> > I still don't see the point in keeping idle threads around.
>
> A mutex as its currently implemented on modern day systems has a
> list of tasks attached to it that are blocked on that mutex. These tasks
>
> The overhead is VERY small. Keeping idle tasks costs next to nothing
> for the kernel apart from accounting space overhead (ie. almost nothing).

   Thanks for clarifying, and sorry for spreading suspicion.

> Keeping idle threads around allows them to be started quickly because you
> don't need to go to the trouble to recreate a new thread. Its much faster
> to start up an idle thread than to create a new one. Besides, the creation
> of the new thread causes the parent to do more work, whereas the idle thread
> just wakes up when the scheduler's ready, therefore better context utilisation.

 Agree. I meant that after a spike of requests there will be left large amount of
 threads in idle state, that might never be used again. Creation of threads on
 demand should be there anyway. Or do you mean fixed number of threads?
 Idle threads still consume resources (stack at least) so I think its good to
 timeout them after some idletime. I believe Apache does something like that
 also.

> > You've got var wrong. Also applies for 1 CPU with thread switch after x++
> > Of course, as you insist on single writer, this would is avoided.
>
> Andres, we are all perfectly well versed with race condition theory.
> You are missing the point here in that we are not talking about a multiple
> writer/reader model. We are talking about a SINGLE writer model, whereby
> the readers can just poll a value AND THEY DON'T CARE is they miss it the
> first time, 'cos they'll catch up next time 'round.
>
> I implemented the asyncio stuff here using exactly the same model.
> It fits for squid. I know.

 OK, OK, I give up. You've been there, I haven't. I just was suspicious. ;)
 
> I fail to see why you're arguing so hard against this. Understand
> the model please, before attacking it.

 Perhaps due to my lack of appropriate coding experience.. I'm basing my
 thoughts on "common sense" ;) and instead of knowing it works, I can't
 see from here how it works and is efficient. Please don't judge me hard
 for my ignorance. I would love to see some working code with this model
 to get an idea.

 regards,

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:43 MDT