[email protected] said: > Wouldn't your patch result in the signal thread sleeping forever in > the scenario you describe? I'm not saying it shouldn't, it just not > what the patch immediately reads like in conjunction with your > description.
Yes, that is the intention, in the first instance. In the second instance, I will need to tackle rumprun-xen issue #15 (implement support for "xl shutdown"), however that is a separate discussion. All I know right now is that I'm going to have to implement some kind of SIGTERM emulation. > First, _lwp_foo() should probably not be used outside of places > where they are necessary. It's more of an internal interface, and > let's keep uses of it to a minimum. That said, I can appreciate > that we don't have an official way to suspend the execution of a > thread indefinitely. Maybe it warrants an issue report? Something > like "if (timeout) nanosleep else for (;;) sleep(100)" might be a > better stepping stone, but no strong feelings about that. The _lwp_foo() interfaces are common to all platforms (baremetal, xen and posix), right? They are internal to the NetBSD libc, so at the same layer conceptually as the calling code I'm implementing? Can you elaborate on why you want to minimise their use by callers at the same layer? > Second, in general, should call the normal interface (_lwp_park) and > not a versioned interface (___lwp_park60) unless there's a strong > reason to do the latter. Will do. OOI, is there a document somewhere that describes how the interface versioning works?
