Good luck on your implementation. I suggest though that you will find too many issues like this to use go routines as the base model for a user. I looked in to threads as a model for jBASE and even with that model, it was going to be too fraught with difficulty. Unless you are considering a production grade implementation with 1000's of users, then I would just implement it as separate go processes. You don't have to use shared memory unless you are trying to copy Universe, but even if you did, you can still use such things in go (though mmap might a better way).
Your bigger problem, if you are trying to provide a complete copy, is reproducing the query language and conversion processor. with all their quirks and strangeness. The compiler is easy compared to that :) Jim On Sat, Aug 10, 2019 at 2:34 AM <reik...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/622c48dd-5909-43a9-923a-ac74a7a8f0b2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFZPyg1GNypf66YWOGYQ2iBB9OYRuk9KWKeX4sYgcviyTfqZxA%40mail.gmail.com.
