From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu, Russ Cox <rsc@swtch.com>
References: <3fab42bfaa9288c3dd261507296e1370@swtch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <3fab42bfaa9288c3dd261507296e1370@swtch.com>
Subject: Re: [9fans] Plan9Ports libdraw open-in-same-window
Message-Id: <20060310135500.11CD5118BA@dexter-peak.quanstro.net>
Date: Fri, 10 Mar 2006 07:55:00 -0600
Cc:
Topicbox-Message-UUID: 116cde92-ead1-11e9-9d60-3106f5b1d025

semctl(2) is probablly the cleanest way on unix. if things really
get hosed, you can use ipcrm to get rid of the semaphore.
i've never had success with unix locking /really/ working.

however, i think the way to address this (and get what paul's after)
is to split src/libdraw/devdraw.c into two parts. _drawmsgwrite
would really write to "/dev/draw" (a p9p filesystem living in
$NAMESPACE like $NAMESPACE/devdraw.$WINDOWID).
access to the mouse and keyboard would need to be similarly
multiplexed.

window(1) could then provide "/dev/{draw,mouse,cons,consctl,label}";
so rio could run this to start a 9term:

#!/usr/local/bin/rc
WINDOWID=`{window}
if (~ $#WINDOWID 1)
	exec the.9term
exit 1

the upside of all this is that window and rio would be the only programs
linked against X. the downside would be extra 9p traffic.

- erik

"Russ Cox" <rsc@swtch.com> writes

|
| > I've been recycling the drawable, but I need to keep a cross-process
| > lock there; what's a good way to keep a lock in P9P?
|
| I didn't answer this.  I don't know how to do a cross-process lock.
| Perhaps you could create a temporary file and fcntl lock it.
|
| Russ