{"action":"created","issue":{"url":"https://api.github.com/repos/supercollider/supercollider/issues/3286","repository_url":"https://api.github.com/repos/supercollider/supercollider","labels_url":"https://api.github.com/repos/supercollider/supercollider/issues/3286/labels{/name}","comments_url":"https://api.github.com/repos/supercollider/supercollider/issues/3286/comments","events_url":"https://api.github.com/repos/supercollider/supercollider/issues/3286/events","html_url":"https://github.com/supercollider/supercollider/issues/3286","id":273124294,"number":3286,"title":"Rework server boot logic","user":{"login":"jamshark70","id":318301,"avatar_url":"https://avatars3.githubusercontent.com/u/318301?v=4","gravatar_id":"","url":"https://api.github.com/users/jamshark70","html_url":"https://github.com/jamshark70","followers_url":"https://api.github.com/users/jamshark70/followers","following_url":"https://api.github.com/users/jamshark70/following{/other_user}","gists_url":"https://api.github.com/users/jamshark70/gists{/gist_id}","starred_url":"https://api.github.com/users/jamshark70/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamshark70/subscriptions","organizations_url":"https://api.github.com/users/jamshark70/orgs","repos_url":"https://api.github.com/users/jamshark70/repos","events_url":"https://api.github.com/users/jamshark70/events{/privacy}","received_events_url":"https://api.github.com/users/jamshark70/received_events","type":"User","site_admin":false},"labels":[{"id":11946377,"url":"https://api.github.com/repos/supercollider/supercollider/labels/comp:%20class%20library","name":"comp: class library","color":"CFFF7D","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":30,"created_at":"2017-11-11T06:35:52Z","updated_at":"2017-11-20T00:38:51Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The components of the server boot process are spread out over too many methods, in too many distinct threads, causing bugs.\r\n\r\nBased on discussion under #3280, I propose we rip it out and rebuild it:\r\n\r\n- There should only ever be one thread watching for the server to come up. Currently, each invocation of `doWhenBooted` creates a new thread. This causes sync problems.\r\n\r\n- After the server comes up, this single thread should call all of the init components in sequence, synchronously. (If any component itself forks another thread, that's its own responsibility.)\r\n\r\n- Those components are (listed here in proposed order of execution):\r\n  - Shared memory initialization\r\n  - Request notification messages --> get clientID from scsynth\r\n  - `ServerBoot`, used by:\r\n    - NodeWatcher\r\n    - SynthDescLib\r\n    - ProxySpace\r\n    - ServerMeterView\r\n    - Volume\r\n  - `ServerTree`, used in... lots of places\r\n  - User functions given to `waitForBoot` or `doWhenBooted`.\r\n\r\n- We can't consolidate ServerBoot and ServerTree, because the latter also happens after cmd-.\r\n\r\n- We can't consolidate CmdPeriod and ServerTree, because one is for stopping and one is for resetting.\r\n\r\nStill to be decided:\r\n\r\n- The final order of init components.\r\n- Do the items that add themselves to `ServerBoot` and `ServerTree` need to be added in a specific order? (Currently we are assuming they don't... and, they add themselves in `*initClass`, whose order we already know to be unpredictable.)\r\n- Should `waitForBoot` / `doWhenBooted` functions to be added to `ServerTree`, using a proposed `doOnce` method?\r\n- If server boot fails, what should happen to `waitForBoot` / `doWhenBooted` functions?\r\n  - If the decision is to cancel these functions, then we need to improve the logic to detect a server process that quits during the startup sequence -- the language should recognize quickly that the server went down, instead of blindly waiting for 20 seconds.\r\n\r\nDid I miss anything?"},"comment":{"url":"https://api.github.com/repos/supercollider/supercollider/issues/comments/345564416","html_url":"https://github.com/supercollider/supercollider/issues/3286#issuecomment-345564416","issue_url":"https://api.github.com/repos/supercollider/supercollider/issues/3286","id":345564416,"user":{"login":"jamshark70","id":318301,"avatar_url":"https://avatars3.githubusercontent.com/u/318301?v=4","gravatar_id":"","url":"https://api.github.com/users/jamshark70","html_url":"https://github.com/jamshark70","followers_url":"https://api.github.com/users/jamshark70/followers","following_url":"https://api.github.com/users/jamshark70/following{/other_user}","gists_url":"https://api.github.com/users/jamshark70/gists{/gist_id}","starred_url":"https://api.github.com/users/jamshark70/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamshark70/subscriptions","organizations_url":"https://api.github.com/users/jamshark70/orgs","repos_url":"https://api.github.com/users/jamshark70/repos","events_url":"https://api.github.com/users/jamshark70/events{/privacy}","received_events_url":"https://api.github.com/users/jamshark70/received_events","type":"User","site_admin":false},"created_at":"2017-11-20T00:38:51Z","updated_at":"2017-11-20T00:38:51Z","author_association":"CONTRIBUTOR","body":"> Then waitForBoot could keep their limit and onFailure args, because it can pass them to boot,\r\nand doWhenBooted could ignore them, and inform users about that when the args are used.\r\n\r\nHm, yes, that's pretty much what I was thinking. I don't think we should deprecate arguments now (maybe in the future).\r\n\r\nHow about this:\r\n\r\n- Change the default value for `limit` to nil (in the argument declarations for `waitForBoot` and `doWhenBooted`).\r\n\r\n- First `waitForBoot` call sets the timeout. Second `waitForBoot` call (or really, any call to `waitForBoot` where the server status is not `\\off`): if it gets a value for `limit` that disagrees with the previously-set timeout, print a warning (but continue).\r\n\r\n- `doWhenBooted`: If the user provides a `limit`, print a warning and ignore the value.\r\n\r\n- Make it clear in the documentation that the timeout happens in the main server boot process, but is set here for convenience and backward compatibility.\r\n\r\nSo these would be OK:\r\n\r\n```\r\n(\r\ns.waitForBoot({ ... }, limit: 20);\r\n\r\ns.waitForBoot({ ... });  // or doWhenBooted\r\n)\r\n\r\n(\r\ns.waitForBoot({ ... }, limit: 20);\r\n\r\ns.waitForBoot({ ... }, limit: 20);\r\n)\r\n```\r\n\r\n... while this would print a warning (and the second call would be subject to the limit of 20).\r\n\r\n```\r\n(\r\ns.waitForBoot({ ... }, limit: 20);\r\n\r\ns.waitForBoot({ ... }, limit: 50);\r\n)\r\n```"}}
{"actor":{"display_login":"jamshark70"}}