3 ms·

I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (One comment on the basic approach: many languages th

I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (One comment on the basic approach: many languages that use green threads don't scale well in multicore due to issues like lock contention or IO wait.) Preemptive multithreading still leaves the OS with final control (for your "miserly time slice" comment. Which I find very problematic for things like say Loopt where for example you will spend more time waiting for a GPS fix or on network latency than actual computation time...) How does a "virtual" exception handler become cheaper than any other implementation? It seems the work required is roughly the same (catch dangerous situations, jump to the correct handler). I suppose there would be lower context switching costs with the use of green threads (skip a user->kernel->user transition), but I suspect it would require programming without any synchronous anything (all IO would have to be asynchronous probably in order for threads to "yield" back to the virtual task scheduler). (Sorry kind of rambling, I'm pretty much curious about every sentence you wrote ;) I don't think traditional multiproccessing models really pose any control problems that are solved by running a single user thread that does its own scheduling IMO)

stcredzero 18y ago
After my previous post, I was thinking, and it occurred to me that putting the VM in the kernel would skip the user-> kernel-> user transition. So one would put it there, not in user land. Somehow I don't think multicore will be an issue with the iPhone for some time to come. Also, putting all of the user-app background processing on a specially designated processor on a multicore mobile device actually sounds like a good idea. I'm certainly not an expert in this sort of thing. Again, my point is really -- okay, Apple says that OS X is not safe enough for background processes on a phone, so why don't they try this ultra-paranoid VM? As for how I'm thinking of this: there is always some small overhead for real context switches and exception handling. If some malicious program decides to be obnoxious, then this can still be felt by the user. If all user applications are creating background processes and Hardin's "Tragedy of the Commons" takes hold, then my experience with all desktop OS I've seen makes me suspect that the user will still feel some small effect. I was trying to come up with a way that you could eliminate even this. Also, I know for a fact that the virtual exception handler in Smalltalk VMs is a lot cheaper from the POV of the OS. It's just normal execution of the app, as far as the OS and other processes go. I can pop off exceptions like it's going out of fashion and no one else cares. They're like "green exceptions." Programming without synchronous anything is exactly what I had in mind for background code. The OS gets all the advantages. The VM is just the ultra-paranoid option to make sure that there are no unpredictable battery-life or security downsides. (There can still be parts of the API that look synchronous to the background user app code.) The foreground part will need to get the results off of some sort of lightweight message passing mechanism.

stcredzero 18y ago

After my previous post, I was thinking, and it occurred to me that putting the VM in the kernel would skip the user-> kernel-> user transition. So one would put it there, not in user land. Somehow I don't think multicore will be an issue with the iPhone for some time to come. Also, putting all of the user-app background processing on a specially designated processor on a multicore mobile device actually sounds like a good idea. I'm certainly not an expert in this sort of thing. Again, my point is really -- okay, Apple says that OS X is not safe enough for background processes on a phone, so why don't they try this ultra-paranoid VM? As for how I'm thinking of this: there is always some small overhead for real context switches and exception handling. If some malicious program decides to be obnoxious, then this can still be felt by the user. If all user applications are creating background processes and Hardin's "Tragedy of the Commons" takes hold, then my experience with all desktop OS I've seen makes me suspect that the user will still feel some small effect. I was trying to come up with a way that you could eliminate even this. Also, I know for a fact that the virtual exception handler in Smalltalk VMs is a lot cheaper from the POV of the OS. It's just normal execution of the app, as far as the OS and other processes go. I can pop off exceptions like it's going out of fashion and no one else cares. They're like "green exceptions." Programming without synchronous anything is exactly what I had in mind for background code. The OS gets all the advantages. The VM is just the ultra-paranoid option to make sure that there are no unpredictable battery-life or security downsides. (There can still be parts of the API that look synchronous to the background user app code.) The foreground part will need to get the results off of some sort of lightweight message passing mechanism.