Ahh sorry I thought an strace would help. It might take me a bit to get an actual stack trace as I'd have to set up my build environment with debugging symbols.

The reason I was recreating QNetworkAccessManager is because I was under the impression that I needed to do so when I lost network access (m_mgr->networkAccessible() != QNetworkAccessManager::Accessible). That's what a user said on this stack overflow post. Is that incorrect? If I could just used something like setNetworkAccessible() that would avoid this whole mess. I've tested out removing the QNAM deletion and the exception does not occur.

I guess I am sort of confused in general about what QNetworkAccessManager::NetworkAccessibility even represents? It's not going to alter the actual network state, NetworkManager handles that

@Xatyrian said in How to use QSocketNotifier on write mode on sockets:

all the time even if there is nothing that has been written !

It is right behavior, please read how its work (e.g. about select() and so on).

It need to use like this (e.g. for writing):

Add data to be written to some internal buffer. Enable the write notifier. When the write notifier fired, just take all data from the buffer and send to ::send/::write. When the write notifier fired again, check for p.3.. If a buffer is empty - just disable wrute notifier.

AFAIK, there are no ways to know that the data are written physically, to client.

BTW: You can use qtserialbus module which implements the SocketCAN support (as I can see from your tag), just use a newest Qt version, as 5.3 is too old.

Thanks for all. I should test it , if it works I will put the code completely here.

Hi,

since I am convinced that somebody else will also have similar problems I wrote a tutorial how to create a multithreaded server:

https://five-s.de/en/how-to-create-a-multithreaded-server-in-qt

Best regards