On 2013/04/12 12:20:23, iant wrote:
*** Submitted as
https://code.google.com/p/go/source/detail?r=64bd7ce0c817 ***
runtime: use UMTX_OP_WAIT_UINT on FreeBSD
UMTX_OP_WAIT expects that the address points to a uintptr, but
the code in lock_futex.c uses a uint32. UMTX_OP_WAIT_UINT is
just like UMTX_OP_WAIT, but the address points to a uint32.
This almost certainly makes no difference on a little-endian
system, but since the kernel supports it we should do the
right thing. And, who knows, maybe it matters.
*** Submitted as
https://code.google.com/p/go/source/detail?r=64bd7ce0c817 ***
runtime: use UMTX_OP_WAIT_UINT on FreeBSD
UMTX_OP_WAIT expects that the address points to a uintptr, but
the code in lock_futex.c uses a uint32. UMTX_OP_WAIT_UINT is
just like UMTX_OP_WAIT, but the address points to a uint32.
This almost certainly makes no difference on a little-endian
system, but since the kernel supports it we should do the
right thing. And, who knows, maybe it matters.
unsupported, release of FreeBSD (7.0 plus security patches), such that
running "go version" would take 60 seconds to complete (or 5 seconds
under ktrace). It appears, from kdump, that the code enters a tight
loop with 441,722 instances of "_umtx_op -1 errno 22 Invalid argument"
in the output, and the same parameters passed every time.
Since the code supporting UMTX_OP_WAIT_UINT went into FreeBSD in 2007 (
http://svnweb.freebsd.org/base?view=revision&revision=173800 ), I
suspect that leaving this change in Go is correct, but perhaps there
could be some better error detection?
Reverting this change resolved the issues for me.
https://codereview.appspot.com/8699043/
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.