On 2016-07-18 15:47:58 -0400, Robert Haas wrote: > I think the risk profile is exactly the opposite of what you are > suggesting here. If we provide an option to compile the server with > all global variables converted to thread-local variables, there's > really not a whole lot that can break, AFAICS.
Using TLS will slow down things noticeably though. So if we were to go there, we'd have to make up for some constant slowdown.
Does TLS really have more of a performance impact than process context switches?
Genuine question, I'm clueless in the area.
> We'll technically be multi-threaded but the code need not know or care > about the other threads; only in the event of a memory clobber can > they affect each other.
But that'll make it pretty hard to take advantage of multi-threading to a meaningful degree. Except for being able to create shared memory after the fact - quite useful! - there'd not be much point.
Yeah. TLS is too simplistic. To do any useful parallel work without serialization/deserialization, some threads need to be in groups with other threads, sharing some data structures but having private copies of others.
That said, TLS can be used as a reasonable default state, then individual data structures extracted and shared more formally when needed. So it's a sane starting point.