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. -- 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/4A4920AF-25F8-459D-A41F-DADEA21B7231%40ix.netcom.com.
