* Thomas Stüfe: >> The main problem for vfork in application code is that you need to *all* >> disable signals, even signals used by the implementation. If a signal >> handler runs by accident while the vfork is active, memory corruption is >> practically guaranteed. The only way to disable the signals is with a >> direct system call; sigprocmask/pthread_sigmask do not work. >> >> Does your implementation do this? > > I understand. No, admittedly not. But we squeeze the vulnerable time > window to the minimal possible: > > if (vfork() == 0) exec(..); > > which was a large step forward from the stock Ojdk solution. > > While not completely bullet proof, I saw not a single instance of an > error in all these years (I understand those errors would be very > intermittent and difficult to attribute to vfork+signalling, so we may > have missed some).
Well, such tight races never matter until they suddenly do. I'm always amazed how races previously thought impossible reproduce reliably with high probability, given the right circumstances. The highlight so far was a single-instruction race (not even a data race) in our condition variable implementation, which broke our iSCSI implementation. >> > The current posix_spawn() implementation was added to glibc with glibc >> > 2.24. So, what was the state of posix_spawn() before that version? Is >> > it safe to use, does it do the right thing, or will we encounter >> > regressions? >> >> It uses fork by default. It can be told to use vfork, via >> POSIX_SPAWN_USEVFORK, but then it is buggy. For generic JDK code, this >> seems hardly appropriate. > > Are you sure about this? The coding I saw in glibc < 2.24 was that it > would use vfork if both attributes and file actions were NULL, which > should be the case with the OpenJDK and jspawnhelper. Oh, right. All the more reason to backport the glibc 2.24 change. 8-) Thanks, Florian
