diff options
Diffstat (limited to 'docs/on-waiting.txt')
| -rw-r--r-- | docs/on-waiting.txt | 64 |
1 files changed, 64 insertions, 0 deletions
diff --git a/docs/on-waiting.txt b/docs/on-waiting.txt new file mode 100644 index 0000000..850d4d6 --- /dev/null +++ b/docs/on-waiting.txt @@ -0,0 +1,64 @@ +This system has an interesting problem that will eventually +need to be solved. I can't think of any system that has +ever fixed this. The thing that worries me is what happens +if a program sends a message to another program, but never +gets a response. + +This could happen due to a bug in the server application, +or it could even just be that the program does not accept +messages. In any event, if the client waits for this +message, it will have to wait forever. + +This shouldn't affect the end-user too much. If a shell +process takes too long to return, then it should quickly +say: + +"This long-running process will run in the background. Type +<some-command> to poll its status." + +But other programs might either decide that the program +won't take too long, or that it can't really continue until +the other program responds, so there's no point in polling. +But a bug could make both of these assumptions false, +resulting in lag. + +The obviously solution would be to remove the wait +function, but many programs will see this and just decide +to poll in a loop without any timeout or error handling, +which doesn't solve the problem. Forcing the client to +specify a timeout does solve this, but on slower hardware +the timeout might not be long enough, and it is difficult +to implement. + +One idea would be to give the server a timeframe of when +it's allowed to respond, and if it fails to do so in that +time, then we assume that it will never respond. This might +be possible with a really smart scheduler, but I'm not +currently able to control the scheduler. Another solution +is to heavily reconsider the current architecture, in such +a way that sending a message to a program is a function +call, and whatever the function returns must be the +response. If the message returns without responding, then +there's no response. That doesn't really solve the issue +either though, because the function could contain an +infinite loop. + +For fun, let's look at the scheduler solutions. I already +have this idea that the UI process should have priority +over any other process. If we stipulate that a poll will +never respond until a frame finishes, then we can +definitely remove the wait function, and it will be obvious +that any waits blocking the UI thread are a bug. +Alternatively, we could say that a server must respond by +the end of the frame. But that would prevent several useful +classes of program. + +Since package IDs are unique, I don't believe there's any +chance of a malicious program exploiting this by pretending +to be a different package. But it is still possible for a +useful package to have a long response time, which could +cause an issue. This vulnerability is not an unforgivable +sin, since every other system has this flaw as well, but it +would be nice if we could somehow prevent it at the OS +level. Then again, it's not like I'm trying to prevent +infinite loops elsewhere. |