I think that Slashdot ate some of your formatting (angle brackets?). I'm not sure how the hash table is used for messaging (you might want to consider Unix domain sockets for messaging, depending on what's going on). But...

You can basically grow shared memory segments on the fly. They're shared in the FS page cache, so if you create a "new" memory mapping on the same backing file that's just bigger, it'll contain all the same stuff in the original segment as the original mapping.

So you just:

a = mmap(..., 2 megabytes,...)

(Use for a while, realize that it's too small)

old = a
new = mmap(..., 4 megabytes, ...)
a = new
munmap(old)

You have to do that per-process, but you can either have the initial part of the memory indicate the mapping length (every time you use it, check the length and reallocate if you're off) or you can use a semaphore or socket message or other OOB message to indicate when to resize.

I don't see how this is (theoretically) any harder in C++ than in Java as far as the problem specifics go (I mean ignoring general reasons that C++ is harder than Java).

Also when they say that a python Manager object is slow, access to it should be considered similar to access to a synchronized method in Java. But reading large amounts of data over it can be problematic, depending on exactly how you're using it.

Depending on your access needs and where your bottlenecks are, I'd also consider using memcached or something like that if you think you might ever expand to multiple machines.

Go doesn't have support for fork without exec, or at least didn't last time I looked at it.

I need async execution of things with read access to lots of data, and write access to their own data.

This sounds like shared memory segments to me. You can enforce memory protection by having separate mappings per process that are only writeable by the owner, with the processes running as separate users. That's safest but requires separate users and can be a headache for some tasks. Alternatively you could rely on the open/map calls being right and use read-only mode there but run as one user (you'd still protect against random pointer bugs, mistakes about which data structures you're writing into, etc as long as the open calls were correct).

ALL I need is synchronization

What kind of synchronization? What are your performance requirements? You may want want to consider simple mutexes, spinlocks, token passing, or read-copy-update depending on what you're doing.

BTW the basic architecture choices are similar across most languages; whether it's C or Python or Lisp or C++ or whatever, you're looking at a handful of common primitives for synchronization and data sharing, often with thin language-specific wrappers around them.

The most common times that there's a major difference is when either in a highly functional language designed around concurrency (e.g. erlang) or a language that isolates you so much from the environment that you can't easily use common primitives (Java's inability to get to multiprocess calls is the most obvious example).

I'd need to know more about your app to make a real recommendation, but in general for multiprocessing I'd use fork without exec to spawn new processes; they will share memory in a copy-on-write manner, so the python interpreter itself and other read/execute only memory will be shared between all processes.

There are numerous approaches to data sharing--sockets/pipes for streaming data and memory-maps for shared memory segments (memory maps are generally preferrable to SysV shm segments, IMO), and either token passing via pipes or something like multiprocessing.Lock for synchronization.

Your cells may want an event-driven state machine model. It's tough to say without knowing more about the app.

But Python doesn't handle multi-processing well

Python's great for multi-processing, much better than Java (which has no built-in solution for multiple processes/tasks, requiring you to throw out the benefits of protected memory or resort to hacky multiple JVM solutions with home-brewed synchronization primitives in order to take advantage of multiple CPUs).

Java's better for multi-threading, but that's usually a poor approach to multi-processing and in the real world the GIL problems with Python are often (but not always) overstated--e.g. the GIL is released by C extensions, so if you're using numpy or PIL or something then it's a non-issue much of the time. And Python has excellent support for fork-without-exec, shared memory maps, and other things that are important to good multiprocessing.

Either:
1) You want to use the phone while driving, in which case you're not going to use such an app; or
2) You don't want to use the phone while driving, in which case you can simply not use the phone.

The first question should have been "Who are you and why should I care?".

He did the "Code Monkey" song, as you note. He also composed music for the Left 4 Dead 2, Portal, and Portal 2 soundtracks, and did the theme song for the TV show Mystery Diagnosis. He's featured weekly as the house musician/sometime question designer on NPR's game show "Ask Me Another".

And, yes, all Ask Slashdots should have a 2-3 sentence blurb with a link to a biography or wiki entry or something.

The client can detect it (on a plain install, view the cert for the page you're on and you'll see who signed it and whether it's a corporate cert or a self-signed cert). The "problem" at work is that once someone else has control of your hardware then it can't be trusted--they could as easily have installed a keylogger and screen scraper, or whatever. Or have installed a browser altered so that "view cert" shows a different cert from the one actually being used. The client isn't trustworthy, which means nothing at all is trustworthy.

You're relatively safe if you do your own OS install and keep things locked down, though even there the hardware manufacturer(s) could be snooping on things. At some point you have to weigh what is enough trust vs. having the tools you need to accomplish your goal (a powered down, non-networked machine is pretty trustworthy, but also relatively useless).

And they are basically Starflight "resurrected".

I wouldn't even say they were "inspirations". Star Control 2 was a spirtual successor to Starflight, except for some cool arcade combat added in--aside from that, the game is mechanically pretty similar with the same kind of intergalactic maps, system maps, planet exploration, etc.

They're close enough that I'd almost say SC2 is a rip-off of Starflight, except that Paul Reiche was one of the lead designers on both and I'm not sure you can rip off yourself. But it's a much closer relationship than just "inspired by".

Reiche also the primary guy responsible for Archon (which is in some ways an inspiration for the combat arena part of Star Control 2, though very much more a loose inspiration than an obvious predecessor) and was one of the early TSR Dungeons and Dragons guys.

The Halting problem still doesn't apply to an iphone, though. Or the 2036 equivalent thereof. Or anything that can ever be built, as far as I can see. It relies on infinite memory to make the set of programs it can run innumerable.

Well, there is one small difference. With an AI, one can always, precisely, deconstruct why and how the system makes the decision that it makes

This is false. There are whole papers dedicated to how useless deeply trained neural nets are in actually understanding intelligence, because they're so complicated that we can't understand why they make particular decisions post-training.

No, the sections I quoted are for the built in headset speaker used for calls. The numbers are all above average for call quality and average for volume. I'm not sure how their subjective judgement said "below average", given that every single one of the objective measurements was average or above. It's not the loudest or best speaker out there, for sure, but it's better than most.

I hope it isn't a mildly revamped G2! The G@ has a below-average loudspeaker

There are a lot of decent criticisms of the G2. The SlideAside is pointless (and doesn't work with a ton of common Android apps), the screen is too big for some people, the buttons on the back are something you can adjust to but they're needlessly quirky and more prone to accidentally being pressed in your pocket than side-buttons are. I'm still not sold on having the headphone jack on the bottom instead of the top.

But the speakers? The G2 has virtually perfect frequency response and a very low distortion level according to:

GSMArena, for one, actually measure the volume. ...who also measure frequency response and other components of sound quality.

They note that the speaker on the G2 is better than average sound quality, though average volume-wise. There's absolutely nothing in their tests indicating a below-average speaker:

http://www.gsmarena.com/lg_g2-review-982p8.php

The LG G2 showed nicely clean output in both parts of our traditional audio quality test. The smartphone got pretty decent scores, but was led down by its volume levels, which were only average.
The scores stay close to perfect even when you plug in a pair of headphones. The stereo crosstalk worsens a bit but the rest of the readings are virtually unaffected (frequency response actually improves a bit). Unfortunately, the volume levels remained just as uninspiring.

Which seems like they're heavily over-weighting volume--unless you're hearing impaired enough that you normally max the volume on your handset, then maximum volume is far less important than the audio quality. But even by their weighting, it's still good audio quality with average volume level.

But the Nexus 5 will probably be half the price of the G2. And run stock Android and receive updates.

The last sentence is why I wrote "the Nexus 5, presuming it follows the Nexus pattern, will run a standard Android OS and UI (and get faster OS updates)".

I'm not making a case for either phone being better, simply saying that the idea that one is a mildly tweaked version of the other is laughable.