Seems hard to believe. How fast is your box? 750ns does not sound plausible for the round-trips needed.
-
-
Replying to @RichFelker @pcwalton
It would only be for compatibility, similar to the Windows implementation, i.e. the performance shouldn't really matter all that much.
1 reply 0 retweets 0 likes -
It lets you use legacy code using blocking system calls without it blocking everything, but it wouldn't be the preferred way to do I/O.
1 reply 0 retweets 0 likes -
BTW, Go still only inserts yield points in function preludes. You can still block indefinitely by simply having a long loop with no calls.
1 reply 0 retweets 0 likes -
https://github.com/golang/go/issues/10958 … since it doesn't support any kind of async preempt to deal with tasks that aren't yielding on their own.
1 reply 0 retweets 0 likes -
seccomp-bpf wouldn't know if read is going to be non-blocking since it's a setting on the file rather than a parameter to read/write though.
1 reply 0 retweets 0 likes -
So doing it that way is going to hurt performance of proper idiomatic code too. Can't see a way to tag read/write calls for seccomp to see.
3 replies 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
Also, you can use MSG_DONTWAIT on sendto(2) and BPF can see that, no?
1 reply 0 retweets 0 likes -
Replying to @pcwalton @RichFelker
That works for sockets, not everything else like pipes.
1 reply 0 retweets 0 likes -
They should really have it for read/write because setting non-blocking mode on files shared with other processes can break them.
1 reply 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.