This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: System-wide mutexes and pthreads


"Robert Collins" <robert.collins@syncretize.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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]