In message <[email protected]>, Alexei Fedotov writes: > > Mark, > Thank you for starting a discussion. Could you please share your > understanding of few questions? > > 1. How serious is a performance penalty caused by wrapping syscalls?
My issue was more to do with the added complexity in the code and the fact that wrapped/restarted syscalls can never behave in quite the same way (w.r.t. timing particularly) as unwrapped calls. As an example of the complexity issue, the calls which need wrapping vary on different platforms and some calls may or may not need wrapping depending on their arguments. On Linux, some calls need wrapping depending on the kernel version. It may be that we end up wrapping too many calls (and probably all invocations regardless of arguments) to cover the possible cases and assume that EINTR is only resulting from instances where we are supposed to restart/retry. So arguably the complexity is in figuring out which calls must be wrapped rather in the implementation of the wrapping itself. I think there are probably around 100 syscalls which can return EINTR and should probably be wrapped. I hope we don't need to wrap them all. > 2. Do I understand correctly that wrapping logic is the same for > wrapping spurious syscall interrupts? Almost. For some calls it literally means retrying with exactly the same arguments. For calls with timeouts you need to track the amount of time that has been consumed and adjust the timeout accordingly. We should probably try to figure out if it was the SIGUSR2 signal that interrupted us and not some other signal that really should result in an error. > 3. We agreed earlier to call DRLVM as Harmony VM. Is it to be revised? We did? I must have missed that. Can you provide any pointers to this discussion? > Here are few my answers, all AFAIK. > 1. BEA VM used signals for suspension, which resembles Harmony VM scheme. > 2. I believe there are alternatives, for example if OS fully supports > thread cancellation points. > 3. If the performance impact is quite low and the wrapping logic is > pretty simple, the fix might be easier to do in class library. I'm not convinced it is easier but from Gregory's comments it would appear that use of signals is common enough among VMs that classlib probably should learn to live with them. > 4. I have memorable experience how much does it cost to rewrite thread > suspension code. Two mighty champions re-implemented threading > subsystem using portlib threading API, and this resulted in a year of > painful debugging. Though we may ask some GSoC student who does not > know fear to try. :-) I thought DRLVM used it's own version of the portlib threading API? It certainly seems to have additional exports compared to the classlib one. Regards, Mark
