On Fri, Aug 9, 2019 at 8:34 PM wrote:
> 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?
>
>
My spider sense (intuition) says you
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
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
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,
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
