[zeromq-dev] Thread-safe sockets (cont.)

[john skaller]

Just a comment on the *misconception* that it is OK to do thread
safety in a binding or application logic.

No, it isn't. The reason is illustrated by a counter example:

1. CPython-ZMQ binding.
2. CPython-fun-twister stuff client API.

The problem is that (1) might add thread safety.
But (2) doesn't call (1). It calls the C API, just as (1) does.

So now, there's no safety. Because the lifted API is not 
the only one available, there's no way to enforce sharing.

Another trivial example: a C program hosting embedded Lua
code. Same problem.

Placing the mutex lock *inside* the C APi enforces sharing
over all clients including all bindings. It doesn't enforce sharing
on those daring to use the raw C++ code -- but it is optionally
available because the mutex is in the raw C++ class object.

There is an analogue in Posix: optional locking. It's fairly useless.
Because anyone can write into a locked region of a file by ignoring
the locks. 

It's not entirely useless but in todays world software is so complex
people want rigid guarantees of correctness for some things, because
there are always a heap of other things where there are no assurances:
[casts in C .. dynamic typing in web applications OMG what a regressive
step in CS]

--
john skaller
skaller at users.sourceforge.net