On 12/13/23 12:04, John Levon wrote:
>
> These two functions are currently private to libvirt, hence not available to
> consumers. Would it be possible to make them public? Without them, there's no
> way to do any libvirt call without stomping on an existing error that you may
> want to preserve.
>
> I have multiple threads sharing a remote connection (to local libvirtd). I need
> to be able to handle connection drops (e.g. libvirtd restart). Long story short,
> the only approach I've found that actually works properly is that there's one
> main conn object, each thread has a virConnectRef() to it, and whenever a thread
> gets an error, we check in the error callback if !virConnectIsAlive(). If so, we
> close the thread's conn, and potentially also clean up the main conn.
>
> Then when the error gets returned from the relevant library call, we try to
> re-connect.
>
> However, virConnectIsAlive() stomps on the thread's error, meaning we lose the
> context on a real, non-connection-related error.
>
> So I need to be able to save and restore in the error handler.
>
> Given how much these are used inside libvirt code already, it feels likely it
> would be useful in other public cases too.
>
> Thoughts?
>
Yeah, it makes sense. I can see it used also in cleanup code (just like
we do in our code). For instance:
void func()
{
...
if (virDomainCreate(dom) < 0)
goto cleanup;
...
cleanup:
/* save error here */
if (dom)
virDomainDestroy(dom);
if (conn)
virConnectClose(conn);
...
/* restore error here */
}
Trouble is that every public API resets the error (by design). And while
the error struct is public (which means users can write functions to
create its copy), we already do have functions for that. So let's just
expose them.
Michal
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
