On Mon, Jul 21, 2014 at 10:09 AM, Saúl Ibarra Corretgé <[email protected]> wrote:
> On 07/21/2014 09:58 AM, Andrius Bentkus wrote:
>> The reentrant library is a big undertaking ... There are so many
>> places that code needs to be changed.
>
> I haven't looked at the PR very closely yet. I'd be ok with merging
> parts of it, but I don't want to go and change the locking primitives
> APIs now. We can do that after 0.12.

I postulate that the locking APIs are already well-designed and don't
need changing.

The *_init() functions pass on errors because resource allocation can
fail at run-time.  Errors elsewhere however always indicate misuse of
the API - i.e. an application bug - and I don't see a compelling
reason to pass those on to the caller.

EDEADLK, EINVAL or EPERM in uv_mutex_lock() or uv_mutex_unlock() tells
you you're doing something wrong.  There is no real going forward
after that because it means there's a bad assumption in your
application somewhere; things can only get worse after that, not
better.

The only sensible course of action under such conditions is to
terminate the process.  It makes tracking down the bug easier and
gives the programmer an incentive to fix it because your program won't
run if you don't.

As a general criticism of pull request #1374[0], blindly replacing
asserts with returns is not the way forward.  I agree that libuv's
current approach to returning versus aborting is somewhat haphazard
and inconsistent.  Making that more uniform is a good thing but for
every such change, you need to ask yourself: "Is there a legitimate
reason for the application to be in this state?"  For many of the
changes in #1374, the answer is - in my opinion - an unequivocal "no."

[0] https://github.com/joyent/libuv/pull/1374

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to