9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] rsynth, yes enjoyed much
Date: Mon, 26 Apr 1999 08:40:02 -0500	[thread overview]
Message-ID: <19990426134002.a-a1tJ5j-2u_eFFM06znuqdVzmSgHIiLroR_3R9CZzI@z> (raw)

>>perhaps you could
>>convert libgdbm to use libc directly.
>
>Yes, however, I'm now begin to doubt it's worth for Plan 9.
>Plan 9 has not any dbm utility other than ndb related, which
>suggets it doesn't important to the system, doesn't it?

Remember that the file servers are accessed by many
terminals and cpu servers and you *must* support
multiple users in any access method.  With dbm
type routines the system will need file locking, etc.

Looking at a 9P data store, there is no reason why
you can't store data using names as keys.  The key
access looks like a hash mechanism (an open/read of
a directory has no particular order).

/* create the data store */
Tcreate tag topdirfid name_table CHDIR|0777 0
Rcreate tag fid qid
Tclunk tag fid
Rclunk tag fid
Twalk tag topdirfid name_table
Rwalk tag dirfid qid

/* for each name */
Tcreate tag dirfid name 0666 1
Rcreate tag fid qid
Twrite tag fid offset length pad data
Rwrite tag fid length
Tclunk tag fid
Rclunk tag fid
...

/* done */
Tclunk tag dirfid
Rclunk tag dirfid

To access the data for a key:

Twalk tag topdirfid name_table
Rwalk tag dirfid qid

/*for each name*/
Twalk tag dirfid name
Rwalk tag fid qid
Topen tag fid 0
Ropen tag fid qid
Tread tag fid offset length
Rread tag fid length pad data
Tclunk tag fid
Rclunk tag fid
...

/* done */
Tclunk tag dirfid
Rclunk tag dirfid

Since 9P is native in the entire system, it seems the
most natural way of handling data.  Performance
requirements, of course, are handled in the
implementation.

David Butler
gdb@dbSystems.com




             reply	other threads:[~1999-04-26 13:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-26 13:40 G.David [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-05-01 13:02 okamoto
1999-04-27  0:54 okamoto
1999-04-26 17:04 forsyth
1999-04-26  7:29 okamoto
1999-04-26  6:51 forsyth
1999-04-26  4:20 okamoto
1999-04-25 21:50 Scott
1999-04-25 17:42 Russ
1999-04-25 11:22 forsyth
1999-04-25  7:57 okamoto
1999-04-23  9:53 forsyth
1999-04-23  8:48 okamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19990426134002.a-a1tJ5j-2u_eFFM06znuqdVzmSgHIiLroR_3R9CZzI@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).