/srv/irclogs.ubuntu.com/2017/03/11/#ubuntu-devel.txt

=== 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
ogra_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 ?14:21
=== asac` is now known as asac
zygamwhudson: hey19:45
zygamwhudson: would you mind having a look at a patch for golang19:45
mwhudsonzyga: um ok but i'm not really here (sunday and all)19:45
zygamwhudson: haha, I didn't anticipate an instant reply ;)19:46
zyga:-)19:46
mwhudsonheh19:46
zygahttp://paste.ubuntu.com/24159510/19:46
mwhudsonzyga: seems like a good thing, although that really is a hacky workaround19:47
mwhudsonzyga: you'll also need to cover the non-cgo case19:47
zygamwhudson: where is that?19:47
mwhudsonzyga: good question :)19:47
zygamwhudson: I think that it is a hack but given the fact that we exec it cannot hurt19:47
zygaexec will replace all the threads19:48
zygatoo bad the kernel doesn't say anything like that19:48
zygaEABOUTTOEXEC19:48
zygaI patched my kernel to see where this fails exactly19:48
mwhudsonoh right yes19:48
mwhudsonhow does this manage to have bad effects other than the message?19:49
zygaand as some people anticipated it fails in kernel/fork.c:103119:49
zygamwhudson: not clear because the thread just doens't get created19:49
zygasomething doens't happen19:49
zygaI didn't run elaborate tests yet19:49
mwhudsonthe non-cgo case is src/runtime/os_linux.go:newosproc19:49
zygathanks, checking19:49
mwhudsonso yeah, add the non-cgo case and come up with a good explanation of why this is a problem :)19:50
mwhudsonand it looks ok19:51
zygamwhudson: does the execing sample attached in the commit message look sufficient?19:52
mwhudsonzyga: so in the bad case, the exec does not happen?19:52
zygamwhudson: and the non-cgo case, is that in os1_linux.go?19:52
zygamwhudson: yes19:52
zygamwhudson: run that in while ./bug; do :; done19:52
zygaand it returns quickly with19:53
zygaruntime/cgo: pthread_create failed: Resource temporarily unavailable19:53
mwhudsonzyga: uh, maybe it's os1_linux.go in older go's, it's os_linux.go in tip19:53
mwhudsonzyga: ah that does sound bad enough yeah19:53
zygaOK19:53
zygawill do19:53
zygafor you it's sunday right?19:53
mwhudsonyeah19:53
zygamwhudson: I'll try to patch that part too, never touched the go compiler19:56
zygaoh, nice sched_yield is already implemented under osyield20:01
zygaI noticed after I wrote the copy :)20:01
zygaI think I got it20:04
jtaylorhm what is the context? sched_yield should not be used20:38
jtayloron linux20:38
jtaylorah read up, you are only using it a couple times that is probably fine20:40
jtaylorbut don't use it for busy looping20:40
zygajtaylor: TBH I'm not yet sure what is the correct solution20:46
zygajtaylor: the case is where one thread runs clone/pthread_create while another one runs exefc20:47
zygaexec*20:47
zygamwhudson: it worked :)21:13
zygamwhudson: but I think sched_yield is not a good idea indeed, the number of retries is unrelible as well21:13
jtaylordon't other programs run into this? or does go just produce a larger amount of threads than everything else?21:15
zygajtaylor: go is special here, normally you don't just create threads in a program that just execs21:16
zygajtaylor: but in go you do21:16
zygahttp://paste.ubuntu.com/24160079/21:16
zygarun this in a loopc21:16
zygacomment out the "C" import for another variant21:16
zygawhile ./golang-bug; do :; done21:16
zygaI have two patches that retry pthread_create/clone up to 1000 times21:17
zygaI can still reproduce it but far far less frequently21:17
zygawhile terrible I'm inclined to sleep :/21:17
zygaor patch syscall21:18
zygato detect exec and set a flag21:18
jtaylormight be something the kernel might be interested in, give userspace the ability to detect a real EAGAIN21:18
zygajtaylor: it is a real EAGAIN21:18
jtaylorthat one seems more like the typical EINTR case not one where retrying again will result in the same result21:18
zygajtaylor: but ... we just care about one of those21:18
zygajtaylor: not the resource contention EAGAINs21:19
jtayloryes but EAGAIN can be a case where trying again won't help as you hit a limit21:19
zygajtaylor: this EAGAIN is also undocumented21:19
jtaylorthe others are not real EGAINs21:19
zygajtaylor: well I think this is up to interpretation21:19
zygajtaylor: but I worry that given how kernel development is done this will not change (userspace sees this)21:19
jtayloryeah, but the kernels input on how this should be handled would be valuable21:19
zygajtaylor: and even if, now you have to roll out a fixed kernel everywhere21:19
zygajtaylor: yes, I agree21:19
zygajtaylor: ideally golang would not do this but I think this is somewhat unavoidable21:20
zygajtaylor: perhaps checkinng syscall.Exec is the way actually21:20
zygajtaylor: just set a flag (retry on EAGAIN)21:20
zygajtaylor: and use that flag to retry21:20
jtaylorzyga: maybe I don't now go to well to really help21:23
jtaylormy 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 today21:24
jtaylorbut used here is probably a reasonable workaround until a maybe better option if found21:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!