There maybe a 4th method is to use something like eventfd/socketpair between go and cgo sides, but it still has a long-blocking call in syscall.Read unless we could add supports of epoll-eventfd/socketpair to the go runtime.
On Monday, September 18, 2017 at 6:43:03 AM UTC+8, Remus Clearwater wrote: > > In the 3rd method `long wait`, if the cgo could emit some dummy > "heartbeat" events > notification periodically (e.g., 10ms), that would be nearly the same as > `C.sema_timedwait` > although there will be a little overhead. > > On Monday, September 18, 2017 at 6:28:11 AM UTC+8, Remus Clearwater wrote: >> >> But according to the man sem_timedwait(3), the abs_timeout is subjected >> to the >> `discontinuous jumps in the system time (e.g., if the system >> administrator manually >> changes the clock)`, and `adjtime(3) & NTP`. >> >> Imaging the system administrator manually put the clock say 10 seconds >> behind, >> thus the `C.sema_timedwait ` is just nearly the same as the method 3 >> `long wait`. >> >> On Monday, September 18, 2017 at 4:41:17 AM UTC+8, Tamás Gulácsi wrote: >>> >>> C.sema_timedwait ? >>> No latency, and with a few seconds for timeout, not too long. >>> >> -- 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.
