[tech] Mac stuff

[Adrian Chadd]

On Thu, Apr 18, 2002, David Luyer wrote:

> Yes:
>   1.  squid has changed the way I code, although it's for the better IMO
> - my
>       code is generally far faster than fork()ing code, and I have taken
>       fork()ing servers and achieved insane speedups by applying the
> squid
>       model (parameterizing the data, and using a poll() or select()
> based
>       central loop)...

Ditto.

> (and threading vs poll()/select()... both add complexity, you could
> argue for
> years about the winner, IMO squid+diskd shows who the winner is:
> poll()/select()
> but with an extra process per disk to hand off blocking disk IO to over
> shared
> memory ... beats squid asyncio - poll()/select() with threads to hand
> off disk
> IO ... and beats all "pure" threading attempts at the same problem that
> I've
> seen to date)

Well, you've seen my initial attempts at a network IO library. :-)

The event-driven single process model for network applications is good.
It forces you to actually _think_ about what you're doing and break
your ideas up into non-blocking chunks.

The trouble is dealing with bits of state when your connection
suddenly dies. Squid has tried to do it using a callback/refcounted
struct - you lock/unlock structs, and you call free() when you're finished -
and everything that uses it does a

if (cbdataValid(pointer))
  { do stuff }
cbdataUnlock(pointer); /* we're finished */

which prevents now-dead structs from actually being read.

I think its the wrong solution, but i haven't figure out
a better one just yet. Guess I should try implementing a simple
http proxy using my library. :)



Adrian