From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <44969c9fd6050a727e8b8f6c8bb27516@coraid.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?
From: erik quanstrom <quanstro@coraid.com>
Date: Fri,  6 Apr 2007 06:58:14 -0400
In-Reply-To: <e510e47e0704060343s71ff9d18mad52e7dc8e1e8e40@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 3ff3eaca-ead2-11e9-9d60-3106f5b1d025

> "s there some reason that I shouldn't implement that in a single-threaded
> server?"

i don't think there's a general answer for this.  the important questions
are probablly
1)  given how long my program may block gathering a response, is it a
problem that all clients block during this time.
2)  will i drop events if i'm busy talking to a client?

if the answer is "no" to both, why bother with more than one thread?

> 
> you've asked that. i'm not an expert about concurrent programming, i've
> never used threads, but here:  http://swtch.com/~rsc/thread/  (it's about
> that subject)
> if you read, you'll see that there that 'block' mechanisms are used to keep
> the system synchronyzed, becuase using that block mechanisms keep the system
> simple too.
> 
> in systens that you arent going to use concurrent programming, you can do
> the synchronization in other ways, more simples, i think.

not all threaded programs are created equal.

csp is not too bad.  locking is subtile and quick to anger.

- erik