I think I can handle the deadly embrace problem. The locks distribute into "slots" based upon inode%slotCount. Just information irrelevant to the observation. At the moment, I use RWMutex to protect each lock table slot since it was more like previous thoughts on this subject. However, I plan to convert them to goroutines, and pass a structure with user information (return channel included, as well as the lock request information). Requesting a lock requires populating appropriate fields in the struct that describe the request. Presently, the mutex will wait if someone has my lock. The channel can queue the request in that case. The return result will indicate success of failure. For a deadly embrace, a new request would say, "return that user's lock request with a failure". Once back, it could go through the channel select and see a "clean up and go away" quit signal, if I really want that user session to exit. Or it could simply return and discover the request failed, and the program could retry or handle its error as it desires. I think the infinite loop situation will need to save some information about each backward branch or call so the object code can receive a break point. If 1000 users are all using the same code, that might not be desirable if it is just some special data case that a particular user has encountered. It would be ugly to have 1000 users hit modified object code if the special case did not apply to them. It is comparable to having them all log out, at the same time, when they are geographically distributed around the world, so you can bounce the database, which I have seen occasionally in production. Not pretty. That will require some more thought. Perhaps a way to automatically migrate things to another instance of the database.
On Fri, Aug 9, 2019 at 12:03 PM Robert Engels <reng...@ix.netcom.com> wrote: > The standard method in nearly all languages including go is to close the > connection from another routine. Alternatively you can use a > timeout/deadline on every operation. > > > On Aug 9, 2019, at 1:34 PM, 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/CAHyJ5Km1ffLtufYk2KbVC8TpPuN6E1dMOgwmyYctHF20Qk7cww%40mail.gmail.com.
