Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <08cd01c1a802$60c6d950$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "egor duda" <cygwin-developers AT cygwin DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
References: <01cd01c1a6dd$4619e550$0200a8c0 AT lifelesswks> <174527779136 DOT 20020128162709 AT logos-m DOT ru>
Subject: Re: Daemon reviewer
Date: Tue, 29 Jan 2002 00:47:49 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 28 Jan 2002 13:47:43.0870 (UTC) FILETIME=[5C84E9E0:01C1A802]


===
----- Original Message -----
From: "egor duda" <deo AT logos-m DOT ru>


> Hi!
>
> Sunday, 27 January, 2002 Robert Collins robert DOT collins AT itdomain DOT com DOT au
wrote:
>
> RC> Gary, will you have to time make some sort of comment on the
code/design
> RC> quality in the next (say) fortnight?
>
> i'm in process of looking into it. the first thing i've stumbled
> over is that cygserver.exe depends on cygwin1.dll. I believe it's
> just wrong and may be a source of difficult to find errors. Is there
> any particular reason for linking daemon with cygwin1.dll? original
> named-pipes-as-transport thingie was made with self-sufficiency
> requirement.

I dont' recall offhand exactly what I used from cygwin itself, but I do
recall needing some functions and not wanting to have to extract them
all by hand. I don't think it will produce any strange results though -
because the daemon's cygwin1.dll instance will be running daemonless.
Ah! I recall. Unix sockets for win95 - that was the key thing I wanted.
Rather than duplicate the cygwin code, allowing for version skew issues,
I used cygwin to manage unix sockets. The only trouble I had was with
cygserver recieving signals - and that was only AFTER I installeda
signal handler.

> second, you wrote that it's mulithreaded, but it's not very clear what
> does that mean.

Ok, I can do a threading model primer if needed, but this daemon uses a
producer-consumer model. There are:
a set of work queues.
for each queue a fixed set of worker threads.
a queue control thread.

Each operation gets a dedicated thread for the life of the operation,
and then the thread resumes waiting.


> Do i understand right that every client connection
> creates a separate thread to handle requests from that client?

No. Every client connection uses an existing worker  thread for each
request. Also a single client can have multiple concurrent requests
(i.e. one from each thread in the client). This is as close to the
optimal performance threaded model, (which is asynchronous non-blocking
IO with 1 thread per processor) as we can get reliably on win95, and
it's very high performance anyway for NT. The reason we have a fixed
number of worker threads is to prevent thrashing during high work load
periods (I've never hit the default limit). Any requests recieved while
ALL threads are busy will get queued and the queue head is dequeued by
the next thread that finishes a task - without context switching. The
threads are not ordered, so ideally NT/9x's kernel will let long-term
idle threads swap out, and preferentially signal threads that have
handled more requests. If we ever get all the threads active at once,
then the dequeuing code becomesactive and the threads will work at full
efficiency. (see threaded_queue.cc::worker_function).

The worker threads are somewhat specialised, but for a given
queue_request  hierarchy, can handle any requests via overridden
process() methods. (This is only particular relevant when looking at the
process cache - SHM related stuff - because all the cygwin<->daemon
calls will get handled by one queue and set of worker threads.)

We can opt for a runtime, or even load tunable number of threads, but
that shouldn't be needed (IMO).

> If it's
> so, i'm afraid i don't understand what all those Interlocked* calls
> and synchronization-related FIXME:'s are for. For instance, in
> cygserver_transport_pipes.cc (transport_layer_pipes::init_security)
> there's a FIXME: comment about the need of something like
> pthread_once. i don't see why it's needed. Standard security
> descriptors should be initialized once at the program startup, before
> any new threads are being spawned.

Right. Well the security descriptors are inited when the first transport
object is created.... so there is an opportunity for someone to create
two threads, and have both create a transport object at the same time.
We don't do that in cygsserver, and it's model won't ever do that, but
if someone takes the code elsewhere, they should add syncronisation at
that point.

Anyway, I hope the earlier description explains why the syncronisation
calls are needed.

Rob