[zeromq-dev] errno

[john skaller]

On 15/01/2012, at 6:09 PM, Ivan Pechorin wrote:

> 2012/1/15 john skaller <skaller at users.sourceforge.net>:
> 
>> There's also an issue with atomicity (is that a word?).
>> Doing something THEN fetching the result in a separate operation
>> is dangerous. What happens if there's a context switch in between?
>> 
>> OK, so it can't be a pthread .. but what about a signal, or, in my case,
>> a Felix f-thread (fibre)... the errno value would be corrupted.
>> Windows has fibres too. The problem is even more obvious with bytecode
>> interpreters like Python where you potentially have context switches
>> every instruction, potentially cooperative.
> 
> I've just checked source code of CRT library in Visual Studio 2010 SP1
> and in Visual Studio 2008 SP1: errno is fiber-local both in 32-bit and
> in 64-bit builds.

But it isn't in Felix :) Not that this is likely to be a problem,
but someone COULD do this:

	zmq_thing();
	write(channel,data);
	if errno != 0 do ..

and that errno may have been set by another operation on another fibre.
The write(channel,data) operation yields control.

Of course, the language binder can fix this, even in C++ provided
you don't use the low level interface.

Don't forget, errno might be clobbered by a posix or C function call,
not just a zmq one.

If a function returned the error code, the problem doesn't exist:
the user captures the code in a variable or uses it immediately.

--
john skaller
skaller at users.sourceforge.net