---- On Sat, 16 Dec 2017 07:18:54 +0800 <[hidden email]> wrote ----
> Can someone please confirm that server.internal freezes on boot on current git 3.9? It would be useful to know if this is also the case on 3.9-beta1.
I can't confirm a freeze:
Server.default = Server.internal;
().play; // I hear middle C
But, the IDE's server status bar does not update. The server window in sclang works just fine.
Hm, I'm not sure if the internal server even listens for UDP. If that's the case, maybe it was a bad decision for the IDE to communicate with the server directly instead of going through sclang.
I think that is the case. As a test, I booted the internal server in the IDE. Then I ran a separate sclang from the commandline:
sc3> o = OSCFunc(_.postln, '/status.reply');
-> OSCFunc(/status.reply, nil, nil, nil)
sc3> NetAddr("127.0.0.1", 57110).sendMsg("/status");
-> a NetAddr(127.0.0.1, 57110)
... and that was it. But, if I quit internal, boot local, and do the same thing, the OSCFunc prints:
I had an non-booting internal server for a brief moment. Rebuilding SC did the trick. I'm not sure what went wrong.
Indeed, the IDE server status doesn't light up when the internal server is running. I think it would be best to discourage the use of this particular server. (what is its intended use?). I want to point out that, unlike
the IDE server status, 'server.makeGui' works fine with the internal server.
> On 17.12.2017, at 06:39, [hidden email] wrote:
> On December 17, 2017 12:28:27 [hidden email] wrote:
> > (what is its intended use?)
> Before there was the shared memory interface, the internal server was the only way to support scope and freqscope.
> With SHM, there's no longer any compelling reason to use it (none that I know of).
I'll admit that I'm not up on the details here, but I always thought that
some form of context switch was required for a CPU core to change from one
thread to another, not only one process to another. I'm fairly sure that it
isn't significantly lighter to switch threads in the same process than to
switch to a thread in a different process. Memory management *might* be
different, but I can't imagine that it would be any more or less costly to
save register state in one case or the other.
Saying that "separate apps require context switches" would seem to imply
that threads in the same process would not need them -- I'm quite certain
that's not true. It's impossible for the CPU to suspend the state of a
thread without saving it somewhere.