[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about multithreading with libSSH
[Thread Prev] | [Thread Next]
- Subject: Question about multithreading with libSSH
- From: "Kennedy, Marcus A." <Marcus.Kennedy@xxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Wed, 25 Mar 2020 20:07:33 +0000
- To: "libssh@xxxxxxxxxx" <libssh@xxxxxxxxxx>
All, Client OS: Windows 10 Host OS: Linux User does not enter commands to process but only authenticates. The application does the rest. Think of this like a compilation job for Linux applications that need to launch from a Windows machine. Our approach is this: 1) Link to the Host 2) run the command "mktemp -d BUILD_XXXXXX" on the Host 3) read back the directory name mktemp outputs 4) Copy a couple of tarballs and a script to the Host in the temporary directory 5) cd <temporary director> 6) execute the script 7) Monitor the output (the script will provide coded status messages during the execution). Originally, we had these commands as ssh_channel_write() within OnInitDialog(), but that was the reason that the dialog went into "Not Responding". So, we added a writer thread. The reader thread launches and only calls into ssh_channel_read_nonblocking() with a .5 second wait if no data is present (otherwise, bleed the channel dry). We started with simply writing mktemp -d BUILD_XXXXXX to the channel and read back mktemp's response. To do this, we expected that the prompt and our command would be on the next line read. In fact, the read thread reads what we wrote exactly then the prompt and the command. If we Sleep(500) launching the thread, we only get back the prompt and command. Are there separate buffers on the client side for reading and writing to a channel? Should we be seeing the writes if we write and read the channel at the same time? Is libSSH thread safe? Thanks, Andy
Re: Question about multithreading with libSSH | Alexander Grotewohl <alex@xxxxxxxxxxx> |
Re: Question about multithreading with libSSH | Andreas Schneider <asn@xxxxxxxxxxxxxx> |