[zeromq-dev] errno

[john skaller]

On 15/01/2012, at 12:26 PM, Martin Sustrik wrote:

> Pieter's article about standardisation-by-committee is worth reading IMO:
> 
> http://www.imatix.com/articles:whats-wrong-with-amqp


Actually his title with a bit of poetic licence .. 

"What's wrong with C++ and how Felix fixes it" 

:)


>> I think the right solution to this problem is probably like this:
>> 
>>   errno_t fun_r( ... )  // core function returns error code
>>   int fun(...) { return (errno = fun_r(...)) ? -1 : 0; }
> 
> Yes. That could work. The obvious problem are the functions that return 
> a value (zmq_send, zmq_recv return number of bytes sent/recvd).

The core API just adds a error_t * member to store the error.
That's another option. In some ways cleaner: all the core functions
return void.

> The primary goal of POSIX interface in 0MQ is to make provide a flat 
> learning curve for those already familiar with POSIX API.

I have no problem with providing that interface .. 
I'd just like to use a better one:)

Hence my suggestion to have two interfaces.

Note also: your argument only applies to C programmers.
How many bindings are there? (I'm just adding one more .. )

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.

> Once we start to fix POSIX problems in 0MQ we'll diverge from POSIX API 
> and miss the primary goal of the whole endeavour.
> 
> More discussion is needed about whether addressing POSIX problems is at 
> all in the scope of 0MQ project.

Err .. but 0MQ is specifically DESIGNED to fix a major problem in Posix .. isn't it?

Anyhow, as above: provide a "core" interface, done the right way. At least people
doing language bindings can use the safe  interface. That doesn't conflict
with a Posix style wrapper. And as noted C and Posix are tending to migrate
functions to re-entrant versions anyhow.


>> C++ API
>> ********
>> 
>> Are you sure you want to throw an error any time a function doesn't work as expected?
>> [That's a question :]
> 
> To be frank I've written C++ binding to make writing testing scripts 
> easier. I.e. instead of placing "assert (rc == 0);" after each C 
> invocation, the error it thrown automatically. That reduces test size by 
> ~50%.

Indeed. It's a good reason. [I have to agree because I do that all the
time myself .. a lot of basic Felix bindings simply throw if there's an error,
it makes the language easier to use "as a scripting language"]

> Of course, if C++ binding is to be used for serious work, preferences 
> may be different.
> 
> I guess actual users of C++ binding should speak up here.

Well I'm not yet an actual user of 0MQ, but Felix compiler targets
C++, so my binding will generate C++ but call the C API.

> Still, the C++ API is still a kind of draft. I would say, if you have an 
> clear idea how it should look like, go on and implement it. The actual 
> implementation work should't take more than an hour or so.

I will show the Felix binding when it's done. At the moment I'm doing
a light-weigt binding (which uses the C API, warts and errnos and all).

> Ha. Totally agreed. The 0MQ core is written in C++ but there's not a 
> single exception used throughout the codebase.

What? A Posix weanie writing C++? Blasphemy :)
> 
> The only reason why they are inline is not have to bother with the build 
> system (C++ binding is a single header file).

Fair enough.

> +1 for your analysis. However, I have not enough free time to invest in 
> the C++ binding. If you want to help with this, you are welcome!

Ok. Well the email archives at least have some notes.
Let me try to get it running inside Felix.

One problem: building it. I tried to build from GitHub but all hell broke
lose with libtool. The tarball built fine.

To be a core part of Felix, we can't use your build scripts.
Felix uses fbuild, which is a complete build system written in Python
that runs on all platforms and builds for all platforms from a single
Python script. I have no idea how hard it will be to generate the
configuration information you need.

--
john skaller
skaller at users.sourceforge.net