From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu,  4 Sep 1997 10:40:29 -0400
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] Adding transaction semantics to Plan9
Topicbox-Message-UUID: 61867ad6-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970904144029.4gA-fPHfEqBhJVNfBLQg2ohQhBlsYn3MozbQmoR35bo@z>

[This didn't come in via the mailing list,
I had to pluck it off news]

From: forsyth@caldo.DEmon.co.UK <forsyth@caldo.DEmon.co.UK>
>i'd have put transaction control files in the name space
>of the transaction server.  those files
>would be written to announce and describe transactions,
>and set transaction modes, and perhaps read to discover state.
>i'd do this for much the reason
>that plan 9 has got /net/tcp and /net/ether
>rather than specialised system calls for sockets.

I thought about this first (it is Plan9!).  Adding to each
server an /adm/trans file that could be written with "start",
"abort", "commit", etc.  There are many problems with this.
First, the process may not know all of the servers that are
bound in.  Next, 9P does not preserve process boundaries only
user.  (Look at the 9P calls from a fork some day.)  Even if you
addressed those issues, how does the server know one read/write
from another?  The mnt driver multiplexes things very well.

>it would be useful, however, to see what your new
>system calls are, to get a more concrete feel for why
>you felt you needed them.

The calls are like begintrans(type), committrans(), aborttrans();
pretty conventional.  The kernel would then have to add the transaction
to most messages and allow for some "file systems" to ignore them.
This is where you add 9P messages and the associated entry points
to each 9P server. (Read that as each device driver needs to
be changed to support or ignore transactions.)

The bottom line is that each 9P message (with some added like
attacht, clonet, precommitt, committ, clunkt) would go from
Tblah [tag] [fid] ... to Tblah [tag] [tid] [fid]

David Butler
gdb@dbSystems.com