First commitHEADmain

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.