=== maclin1 is now known as maclin === maclin1 is now known as maclin === JanC is now known as Guest5212 === JanC_ is now known as JanC === JanC_ is now known as JanC [14:21] slangasek, i wiped all calendar data from my phone and re-installed/re-created everything ... how does the TB meeting even end up in any way related to my calendar, i never added it, did someone in canonical do that ? === asac` is now known as asac [19:45] mwhudson: hey [19:45] mwhudson: would you mind having a look at a patch for golang [19:45] zyga: um ok but i'm not really here (sunday and all) [19:46] mwhudson: haha, I didn't anticipate an instant reply ;) [19:46] :-) [19:46] heh [19:46] http://paste.ubuntu.com/24159510/ [19:47] zyga: seems like a good thing, although that really is a hacky workaround [19:47] zyga: you'll also need to cover the non-cgo case [19:47] mwhudson: where is that? [19:47] zyga: good question :) [19:47] mwhudson: I think that it is a hack but given the fact that we exec it cannot hurt [19:48] exec will replace all the threads [19:48] too bad the kernel doesn't say anything like that [19:48] EABOUTTOEXEC [19:48] I patched my kernel to see where this fails exactly [19:48] oh right yes [19:49] how does this manage to have bad effects other than the message? [19:49] and as some people anticipated it fails in kernel/fork.c:1031 [19:49] mwhudson: not clear because the thread just doens't get created [19:49] something doens't happen [19:49] I didn't run elaborate tests yet [19:49] the non-cgo case is src/runtime/os_linux.go:newosproc [19:49] thanks, checking [19:50] so yeah, add the non-cgo case and come up with a good explanation of why this is a problem :) [19:51] and it looks ok [19:52] mwhudson: does the execing sample attached in the commit message look sufficient? [19:52] zyga: so in the bad case, the exec does not happen? [19:52] mwhudson: and the non-cgo case, is that in os1_linux.go? [19:52] mwhudson: yes [19:52] mwhudson: run that in while ./bug; do :; done [19:53] and it returns quickly with [19:53] runtime/cgo: pthread_create failed: Resource temporarily unavailable [19:53] zyga: uh, maybe it's os1_linux.go in older go's, it's os_linux.go in tip [19:53] zyga: ah that does sound bad enough yeah [19:53] OK [19:53] will do [19:53] for you it's sunday right? [19:53] yeah [19:56] mwhudson: I'll try to patch that part too, never touched the go compiler [20:01] oh, nice sched_yield is already implemented under osyield [20:01] I noticed after I wrote the copy :) [20:04] I think I got it [20:38] hm what is the context? sched_yield should not be used [20:38] on linux [20:40] ah read up, you are only using it a couple times that is probably fine [20:40] but don't use it for busy looping [20:46] jtaylor: TBH I'm not yet sure what is the correct solution [20:47] jtaylor: the case is where one thread runs clone/pthread_create while another one runs exefc [20:47] exec* [21:13] mwhudson: it worked :) [21:13] mwhudson: but I think sched_yield is not a good idea indeed, the number of retries is unrelible as well [21:15] don't other programs run into this? or does go just produce a larger amount of threads than everything else? [21:16] jtaylor: go is special here, normally you don't just create threads in a program that just execs [21:16] jtaylor: but in go you do [21:16] http://paste.ubuntu.com/24160079/ [21:16] run this in a loopc [21:16] comment out the "C" import for another variant [21:16] while ./golang-bug; do :; done [21:17] I have two patches that retry pthread_create/clone up to 1000 times [21:17] I can still reproduce it but far far less frequently [21:17] while terrible I'm inclined to sleep :/ [21:18] or patch syscall [21:18] to detect exec and set a flag [21:18] might be something the kernel might be interested in, give userspace the ability to detect a real EAGAIN [21:18] jtaylor: it is a real EAGAIN [21:18] that one seems more like the typical EINTR case not one where retrying again will result in the same result [21:18] jtaylor: but ... we just care about one of those [21:19] jtaylor: not the resource contention EAGAINs [21:19] yes but EAGAIN can be a case where trying again won't help as you hit a limit [21:19] jtaylor: this EAGAIN is also undocumented [21:19] the others are not real EGAINs [21:19] jtaylor: well I think this is up to interpretation [21:19] jtaylor: but I worry that given how kernel development is done this will not change (userspace sees this) [21:19] yeah, but the kernels input on how this should be handled would be valuable [21:19] jtaylor: and even if, now you have to roll out a fixed kernel everywhere [21:19] jtaylor: yes, I agree [21:20] jtaylor: ideally golang would not do this but I think this is somewhat unavoidable [21:20] jtaylor: perhaps checkinng syscall.Exec is the way actually [21:20] jtaylor: just set a flag (retry on EAGAIN) [21:20] jtaylor: and use that flag to retry [21:23] zyga: maybe I don't now go to well to really help [21:24] my alarm clocks just rang on mention of sched_yield as that occurs in lots of old numerics software I work with, written back when sched_yield was more or less equivalent to pause and not what it is today [21:25] but used here is probably a reasonable workaround until a maybe better option if found