This is not a free speech issue. You are allowed to say and write "redskin" anywhere you wish. You just can't trademark it.

Yes, you can. This decision explicitly doesn't revoke the team's right to use the trademark "Redskins". It removes it from the USPTO primary registry, but it doesn't revoke the trademark (in other words, what was an (R) is now a (TM)).

They can't. The plaintiffs were specifically chosen as people who had recently turned 18 and were still eligible to challenge.

They had a trademark on their brand. The feds decide they don't like the mark so they take it away. The owners end up being harmed economically all because the government didn't like the descriptive nature of the brand. They've effectively stifled the free speech of the owner by denying them the use of the mark.

Please read the decision. They have done no such thing, and haven't cancelled the trademark. They've removed it from the primary registry. The team still has full protected (TM) rights, and third parties won't be allowed to make knockoff jersey with the name on it or anything like that. It's just not a registered (R) trademark anymore.

From the decision:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

The trademark exists to protect their business interest in the brand name. The feds aren't canceling the mark because other business entities want to use it, they're canceling the mark because the feds don't like it.

This is wrong. The feds aren't canceling the trademark, period. They are canceling its presence on the USPTO primary registry (where it's not allowed to be under the Lanham act), but it'll still be a (TM) trademark with court protection (just not an (R) registered trademark).

From the decision itself:

This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

The government is not restricting speech at all. The summary is hopelessly dumb: the decision doesn't strip the team of their trademarks, it simply removes them from the USPTO registry as required by the Lanham act. They'll still be protected (TM) trademarks that nobody except the owner is allowed to use, they just aren't (R) registered (which has implications on venue and damages).

From the decision itself:

This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

If you have a CPU-intensive thing, you can use shared memory and binary structs to share it, no need to turn everything into a string.

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.