From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4405D850.4080709@lanl.gov>
Date: Wed,  1 Mar 2006 10:22:24 -0700
From: Ronald G Minnich <rminnich@lanl.gov>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 9p and how can I know when a write is finished
References: <3427729765b4e88fb0db2d794e3cdbc6@cat-v.org>	<4405D2A2.4040505@lanl.gov>
	<82c890d00603010921l4d284202t3c9883c83b139946@mail.gmail.com>
In-Reply-To: <82c890d00603010921l4d284202t3c9883c83b139946@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 079200f0-ead1-11e9-9d60-3106f5b1d025

Gabriel Diaz wrote:
> Hello
>
> Using "normal" files is quite easy to do like ramfs does,
> but if you write commands to a file that should be parsed,
> you should choose when will your parser run, just
> in the fswrite call? if you receive multiple writes, may be
> you end with a split command and your parser returning error.

So you might need a state machine in the thing that handles write for
your ctl file.

If you're worried about conflicting writes from different writers, maybe
you can set the '1' attribute and then only one person gets to open it
and write to it?

We've had this problem in other circumstances (servers hanging off a TCP
line, integral commands not guaranteed) and it's pretty easy to handle
it. Also, take a look at, e.g., the TCL command interpreter -- same
exact problem: you get bits and pieces of a command, and you don't want
to fire until you get the whole thing. It's just a state machine approach.

ron