Deadlock on C function fsw_destroy_session if fsw_start_monitor was called.

[Andrepuel]

fsw_start_monitor will acquire the session mutex and will invoke session->monitor->start() with this mutex locked. The only way to stop the monitor (and thus release the mutex) using the C bindings is to destroy the session, but the fsw_destroy_session will also try to acquire the mutex.
An application that tries to stop the monitoring by destroying the session will deadlock.

[emcrisostomo]

What about line 865:

    session_lock.unlock();

where the mutex is released before invoking:

    session->monitor->start();

Please, feel free to reopen the issue if you have more information to add.

[Andrepuel]

By session mutex, I meant https://github.com/emcrisostomo/fswatch/blob/master/libfswatch/src/libfswatch/c/libfswatch.cpp#L857.

unique_ptr<mutex>& sm = session_mutexes.at(handle);
lock_guard<mutex> lock_sm(*sm.get());

[emcrisostomo]

I've patched the develop branch and now the session mutex is released before starting the monitor. Would you please test it?

[Andrepuel]

In my scenario, I have two threads. The second thread will be running the fsw_start_monitor and the main thread will eventually invoke fsw_destroy_session.
I can confirm that the fsw_destroy_session is not deadlocking anymore on the main thread. However, the second thread will still be stuck in the fsw_start_monitor call due to the the issue #136.

[Andrepuel]

By the way, if you don't mind me asking. Why did you choose the handle approach to identify the sessions in the C API?
With the alternative of returning an opaque struct pointer (struct FSW_SESSION; typedef struct FSW_SESSION* FSW_HANDLE;) you would be able to get rid of all the mutexes and the logic of maping a handle to the actual struct.

[emcrisostomo]

@Andrepuel:

I can confirm that the fsw_destroy_session is not deadlocking anymore on the main thread.

Thanks.

However, the second thread will still be stuck in the fsw_start_monitor call due to the the issue #136.

Please see #143. Basically, a monitor should be stopped explicitly by calling fsw_stop_monitor.

You can try out the release/1.10.0 branch.

[emcrisostomo]

@Andrepuel:

Why did you choose the handle approach to identify the sessions in the C API?

A choice that backfired. I already made that refactoring on release/1.10.0.

[emcrisostomo]

@Andrepuel,

This:

I can confirm that the fsw_destroy_session is not deadlocking anymore on the main thread.

and #143 should be enough to close this issue.

[Andrepuel]

Using fsw_stop_monitor there is no deadlock anymore.