From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  9 Sep 1997 07:39:39 +0100
From: forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk
Subject: [9fans] Porting XaoS (saga continues)
Topicbox-Message-UUID: 61fb3ccc-eac8-11e9-9e20-41e7f4b1d025
Content-Type: text/plain; charset=UTF-8
Message-ID: <19970909063939.N9BTNgRaVfGtFk_KHR-T4UmDS9cNyY7O_g0NU_3Ns_Y@z>

see /sys/src/cmd/disk/kfs/libp/port/qlock.c and related
files for a user-level QLock and RWLockimplementation.  you should
be able to implementat what you need with that.  note too that
sleep(0) will relinquish the CPU.  see /sys/src/cmd/exportfs
and /sys/src/cmd/telco for other examples of multi-process
servers and different approaches to synchronisation.
you'll also find a concurrency-safe version of
malloc.c in at least one of those directories.

most new concurrent programs in Plan 9 are (best)
written in Alef, so not much effort has gone into providing
a complete programming package for the venerable C.

one point that's easy to overlook is that fork(2) notes that rfork(RFPROC|RFMEM)
causes ALL subsequent forks to share data.  consequently, you need to ensure that
einit(...) is called to initialise the graphics event code before you do
the first RFMEM rfork, otherwise things can get a little bit confused.

as to the second question, i'm afraid that Plan 9 graphics supports only
up to 8 bits (0 <= Bitmap.ldepth <= 3).  it's not just 8½; it would require
a fair amount of effort to change.