You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's possible I'm doing something wrong, but I've run into an issue when calling Server::start with an in-use port. A similar issue was reported in #80, but the author closed the ticket without comment.
If you call Server::start and bind fails (say a port is already in use), the start call never returns. The dead lock happens in the Shared::lock call, which calls shared.reset on failure.
The Shared destructor calls close, which at the end attempts to take a writer lock:
// socket.cpp:194, bottom of ::close method.
WLock l(mutex);
if (s != InvalidSocket) {
#if !defined(_WIN32) && !defined(__APPLE__)
::close(s);
#endif
s = InvalidSocket;
}
That writer lock is waiting for the read lock that is being held by the function calling it, leading to the deadlock.
Am I doing something wrong here? I can work around the issue by trying to bind the socket myself before invoking cppdap and verifying that it works before calling start, but that doesn't seem ideal. The calls to shared.reset() inside a call to shared seem suspicious to me, but I might well be misreading the code.
The text was updated successfully, but these errors were encountered:
It's possible I'm doing something wrong, but I've run into an issue when calling Server::start with an in-use port. A similar issue was reported in #80, but the author closed the ticket without comment.
If you call
Server::start
and bind fails (say a port is already in use), thestart
call never returns. The dead lock happens in the Shared::lock call, which calls shared.reset on failure.The Shared::lock method takes a reader lock before calling the function:
The Shared destructor calls close, which at the end attempts to take a writer lock:
That writer lock is waiting for the read lock that is being held by the function calling it, leading to the deadlock.
Am I doing something wrong here? I can work around the issue by trying to bind the socket myself before invoking cppdap and verifying that it works before calling start, but that doesn't seem ideal. The calls to
shared.reset()
inside a call toshared
seem suspicious to me, but I might well be misreading the code.The text was updated successfully, but these errors were encountered: