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 [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
