Background:
UniVerse is a Pick model, multivalue database,
https://groups.google.com/forum/#!forum/mvdbms for some general information.
Multivalue databases permit more than one value in a column for a row.
Since you do not know the size of the column with hundreds or thousands of
values in the column-row, you do not know the size of the record. Access
dictates linked lists to handle variability in record size. So, every row
gets a unique primary key and stored in hash tables with an appropriately
large number of hash buckets for the data - key / value pairs. With good
hashing, I can often access a record in a single disk access. Group (hash
table bucket) locking happens within the environment, while users request
row locking. Each user in UniVerse is a separate O/S process. Locking
activity occurs in shared memory, using assembly test-and-set kinds of
instructions or host-specific semaphores.
After retiring, I decided it would be a fun experiment to build a
clean-room implementation of UniVerse. Go does not do interprocess
communication at the rate that would match the shared memory semaphore
activity in UniVerse. A natural match implements each user as a goroutine.
UniVerse provides an extended BASIC language for accessing and manipulating
table data that runs close to the engine. In a language you can do silly
things like create an infinite loop. In a production environment of 1000s
of users, you cannot simply bounce the environment because one user is
eating a CPU. An admin function to dismiss or kill a goroutine would be
ideal. Not possible in the current Go world.
For an infinite loop to exist, you need to branch "backwards" or call a
routine that calls you back with some possible indirection. (An equivalent
in Go is "for {}" with no break. Here, you would not get back to the
traditional mechanism of telling a goroutine to shut down where one of the
channels for select is the shutdown indicator.) There may be other
examples I have yet to think of. When I "compile" BASIC, I can put checks
into those two functions, call, and branch (to a lower address), without
inducing too much overhead. an unimportant detail is that the BASIC
compiles to a p-code run on a run machine, comparable to a JVM. I might
even be able to find the PC, Program Counter or IA, Instruction Address,
and insert some kind of trap instruction opcode, that would cause it to try
the select statement and see the shutdown channel. But in the general case,
this may be insufficient. I think a "context" timeout would interrupt a
properly long-running program in a way that might be hard to restart if
shutdown was not requested.
As a database, there is also the possibility of deadly embrace. Killing one
of the two (or more) goroutines in a deadly embrace would be useful. This
normally occurs on poorly managed acquisition of exclusive locks on
database table rows. I could forcibly release a lock, but then would need
extra work so that a user goroutine that thinks it exclusively owns a lock,
finds that it does not, and would need to gracefully exit or handle the
situation.
As a goroutine, each user does not have a STDIN, and STDOUT to communicate
with its user. Currently, the user communicates with the goroutine with a
socket connection. I can probably redesign, adding a new goroutine
accepting user requests/commands on a channel, and monitoring the shutdown
channel with a select in a loop. Otherwise, I could not get a goroutine to
shut down if it is waiting on user input from a socket, or a dropped
connection, although that begs the question of how to get the
socket-reading goroutine to now shut down.
The current Go implementation smells of cooperative multitasking. Not a bad
thing, per se, but makes it hard to stop in certain degenerate cases. Have
I missed a way to deal with some of the discussed issues?
The project has certainly been a good way to become familiar with a number
of the Go idioms. (BTW, I happen to *like* the current way of handling
errors!)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/622c48dd-5909-43a9-923a-ac74a7a8f0b2%40googlegroups.com.
