@Joachim-W
I looked at your progress here but have not had an opportunity to examine it further. But here are a couple of points which strike me:

readLine() should read one line from input. It should not matter whether that comes from terminal (with or without pasting) or redirection. The fact that you seem to say sometimes it reads/returns one line and sometimes multiple lines should not happen. A line is a line. The QTextStream may (or may not) buffer further lines which are available (e.g. from redirection) but readLine() should only return a single line.

When reading from redirection you can/should be able to read till "end of file", indicating the end of input. But when reading from terminal there is no "end", user could type more at any time, so no "end of file".

You should not need a timer. One QSocketNotifier notification should be received when there is one or more lines/input available. Process all lines which are available (however you test for that) then exit. That should be it for the redirection case. For the terminal case at some future point a new QSocketNotifier notification should arrive at which point you re-enter and process whatever is available anew. You will need a readLine() call which returns with "empty" when no more input is currently available, or a test which says whether there is any further input available at this point before calling a blocking readLine(). It may be better to call readAll(): that should return all data which is available at that point, I believe, but will not block like readLine() when no further data is there. This will work for redirection too.

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