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:
1. YottaDB uses signal based interrupts – mostly SIGALRM for timer support but other signals as well (SIGINT, SIGUSR1, etc). 2. 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”. 3. 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. SE -- 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.
