Sorry for getting back so late.
Here is the conclusion after many testing:
1. C Call Go is the best method as far as I could find (Thanks Ian!): √
The latency could nearly always keep less than 100us no matter the
system is under light load or moderated heavy load.
2. Socketpair ( Thanks So
On Sun, Sep 17, 2017 at 10:10 PM, Sokolov Yura wrote:
>
> Isn't there a way to pass Go callback to Cgo? In this callback you may do
> anything.
You can't pass a simple callback, but you can have your C code call a
Go function whenever some event occurs. Start a new thread in C, have
it wait, an
And I agree that socketpair and regular read from will also do the job.
https://github.com/prep/socketpair/blob/master/socketpair.go
--
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,
Isn't there a way to pass Go callback to Cgo? In this callback you may do
anything.
--
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...@googl
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 wr
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 t