On Wed, Aug 29, 2018 at 12:23 PM, <est...@yottadb.com> wrote: > > Although I spent some time searching, I have not found an issue quite like > the one I’m experiencing so here goes. We are working to create a set of > Golang wrapper functions/methods that call into an existing database product > (YottaDB) that has a C interface. This was going well until we ran into a > situation where some Golang design attributes and YottaDB design attributes > are clashing. Below are listed some of the long-existing design attributes > of YottaDB that are clashing with Golang: > > > YottaDB uses signal based interrupts – mostly SIGALRM for timer support but > other signals as well (SIGINT, SIGUSR1, etc). > > The design is such that one can specify timeouts for certain functions like > socket connection, socket read, lock acquisition, console IO, etc. The > expectation is that some system call is interrupted, returns an EINTR, which > the code checks for along with a timeout flag set by the actual interrupt, > and the wait for whatever resource is ended as the function “times out”. > > There are timers throughout the code base that behave the same way – > database flush timer, epoch timer, critical section acquisition timer, etc. > These all depend on being interrupted rather than just posting an event on a > queue or something similar. > > > What I noticed when mixing console input and database actions in a Golang > program was I’d get errors from things like bufio.ReadString() that > contained “read /dev/stdin: interrupted system call”, which is of course an > EINTR return. While I was able to add a check for this error (with a > seemingly clumsy string comparison with the above string) and just > ‘continue’ the loop to retry, this solution does not lend itself to all > possible problems this would cause as some failing calls could be deep in > code we cannot or would not want to change (BTW, it does this on both Golang > 1.6.2 on my Ubuntu 16.04 box and on Golang 1.9.4 on RHEL 7.5). > > > My research showed that this issue happens because Golang requires all > signal handlers in the same process with it have SA_RESTART and SA_ONSTACK > enabled but YottaDB cannot do that because of the need to cause *some* > currently running system calls to be interrupted and aborted. I did try it > and sure enough several tests in our regression test system got hangs due to > a lack of timeouts. > > > Is there some workaround for this issue short of redesigning a few hundred > Kloc of C in YottaDB to play better with Golang (not really an option at > this point)? If I had complete control over the threads in Golang, I’d > disable interrupts on all of them except for one bound to a goroutine where > YottaDB was initialized to control what threads got interrupted but I don’t > think I have that sort of control. Or if I do, I don’t know what it is or > how to use it.
I believe this is https://golang.org/issue/20400. Unfortunately I do not know of any good workaround for this problem. Sorry. The process-wide nature of signals makes them very hard to manage in multi-language programs. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
