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: <028001c21252$e92c7ba0$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: "Robert Collins" <robert DOT collins AT syncretize DOT net>
Cc: <cygwin-developers AT cygwin DOT com>
References: <005401c2124e$7cb91a90$0200a8c0 AT lifelesswks>
Subject: Re: System-wide mutexes and pthreads
Date: Wed, 12 Jun 2002 21:51:21 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Robert Collins" <robert DOT collins AT syncretize DOT net> wrote:
> Cygserver coding guidelines:
> 1) Trust nothing. Don't trust Process ID's, access rights or anything
> else. Always check via an alternate path if you are able to.

I never trust anything anyway: sounds just the project for me :-) Having
said that, my current version checks remarkably little on non-NT platforms
:-(

> 2) Use pure win32 code wherever possible. I used pthread_once because I
> could :}, but other than that you'll find it's all native objects. The
> only other big exception being using domain sockets, and that's because
> they are so dang useful for LPC.

I know all about the "I used it 'cos I could" feeling. It's a shame that the
daemon isn't a pure win32 program, but I get the feeling that it will depend
more on cygwin features as it develops, rather than fewer; for example,
configuration or log files should obey cygwin naming rather than raw win32.

> 3) The cygserver needs to be robust. It should never need to wait on a
> user owned mutex or event, and if it absolutely has to wait on such a
> thing should always use a timed wait call.

So far there are no waits on client-owned objects (AFAIK). Certainly I've
had development versions here that don't wait on anything, except the
dumper's attentions :-(

> 4) Latency. Try to get the most bang for each cygserver LPC call. It's
> better to spend a few cycles setting up several parameters than to wear
> the overhead of (say) access checks multiple times.

I'm with you all the way.

Quick status report while I'm here:

*) Nicholas and I are testing the shm code on Win Me (well,
Win-something-or-other non-NT anyhow) and there's some progress so far but
it's not quite there yet.

*) I'm working on finishing off the Posix-conformant shmget(), shmat(), and
shmdt() functionality --- it's about 90% of the way there now, just some
issues in detaching and general clean up left to do (i.e. the nasty stuff).

*) After that it's either adding some synchronization (so it works with more
than one process at once . . .) or finishing the shmctl() and ipcs/ipcrm
functionality. But that's something for another day.

Cheers for the moment and thanks for the reply.

// Conrad