Release loop when close success about uvw HOT 6 CLOSED

I must admit that, although it actually makes sense, it would be probably a breaking change. I'm not sure it's the best choice.
On the other side, to solve the issue you pointed out it's enough to update the close member function as follows:

    void close() {
        auto err = uv_loop_close(loop.get());
        if(err) { publish(ErrorEvent{err}); }
        else { loop.reset(); }
    }

from uvw.

However uv_loop_close() is not idempotent (it will return UV_EBUSY if the loop has already been closed in DEBUG build, or crash straight away in Release build)

Interesting. Actually the documentation says something slightly different:

Call this function only when the loop has finished executing and all open handles and requests have been closed, or it will return UV_EBUSY.

It seems that UV_EBUSY is due to pending handles or requests instead.
Are you sure you've none of them?

from uvw.

In terms of consistency, the best bet is to remove the destructor of the loop and let it be a no-op.
uvw stays true to the behavior of libuv and you've eg to close handles explicitly, it won't close them for you. I don't see why it should close the loop implicitly.
I'm tempted to say that you pointed out a design issue rather then a bug.

from uvw.

It seems that UV_EBUSY is due to pending handles or requests instead.
Are you sure you've none of them?

The issue happens in debug mode because of this.

BTW for Release build the code that can reproduce this issue is even simpler:

int main()
{
	auto loop = uvw::Loop::create();
	loop->close();
}

I'm tempted to say that you pointed out a design issue rather then a bug.

My understanding is that if the loop contains any active handles / requests then there will be references to the loop so the destruction won't be called automatically, so the Loop::close() actually should not be called explicitly?

This seems quite reasonable since if the Loop get destructed but uv_loop_close() returns UV_EBUSY then that means something is wrong with the reference counter. In this case is not the fault of this library.

However this makes the Loop::close() function very confusing -- it's public but you are not supposed to call it.

from uvw.

Quite the opposite.

What I'm saying is that the Loop class should not invoke uv_loop_close. Actually, uvw::Loop should not have an explicitly defined destructor at all.
Instead, you as an user must close explicitly the loop as you would do if you were working directly with libuv. The same happens with the handles after all. This means staying true to the underlying library and that's why I think it's a design flaw rather than an issue.

from uvw.

Right that make sense.

from uvw.