[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support external recv and send callbacks
[Thread Prev] | [Thread Next]
- Subject: Re: Support external recv and send callbacks
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Tue, 30 May 2017 22:04:33 +0200
- To: libssh@xxxxxxxxxx
Hi Joseph, Thanks for your Patch. I have no idea about the call convention to use. That there are two incompatible competing conventions is imho a good sign that we should let a middleware do this for us. Or maybe there's a way to explicitely tell mono or .NET which call convention is being used? Back to the patch: good work. Is there a reason those callbacks couldn't be merged into struct ssh_callbacks_struct? This would make less callback structures (we already got too many) and these are already backward-compatible proof (size field + ssh_callbacks_init + ssh_callback_exists). Another question, what's happening with poll ? There must be a way for libssh to be awakened when there's data to be read on the socket and when write will not block (flow control). How do you integrate this code into your own main loop at the moment ? Aris On 30/05/17 21:30, Joseph Southwell wrote: > You realize if you are going to modify the cmake stuff to > conditionally insert a #define into my callback typedefs there is no > reason you can’t do it to the others if you just disable it by default. > Here is my patch. I am going to submit it on the bug tracker but if > you want to use it before they apply it be my guest. > > > > > >> On May 30, 2017, at 3:25 PM, Jason Curl >> <jason@xxxxxxxxxxxxxxxxxxxxxxxx >> <mailto:jason@xxxxxxxxxxxxxxxxxxxxxxxx>> wrote: >> >> Seeing that cmake is being used, its not too hard. When I compile on >> mingw64, the WIN32 micro is already set. Not om Cygwin, bit that's >> not a typical use case. By not too hard I mean about 1 hoir >> implementation, mostly reading. I can support if you want >> >> >> >> Sent from my Windows 10 phone >> >> >> >> *From: *Joseph Southwell <mailto:jsouthwell@xxxxxxxxxxxxx> >> *Sent: *Tuesday 30 May 2017 21:16 >> *To: *libssh@xxxxxxxxxx <mailto:libssh@xxxxxxxxxx> >> *Subject: *Re: Support external recv and send callbacks >> >> >> >> So, according to >> http://mono-list.ximian.narkive.com/lfOw5Ldl/mono-net-delegate-incompatibility >> MONO and .NET have different requirements on windows (one requires >> cdecl callbacks and the other requires stdcall). If that is still the >> case there isn’t really right answer without adding build options and >> that gets a little out of the area I am being paid to put effort into. >> >> > On May 28, 2017, at 3:19 PM, Jason Curl >> <jason@xxxxxxxxxxxxxxxxxxxxxxxx >> <mailto:jason@xxxxxxxxxxxxxxxxxxxxxxxx>> wrote: >> > >> > >> > On 25/05/2017 16:25, Joseph Southwell wrote: >> >> I found a flaw in this and will be resubmitting it. >> > If you're going to make callbacks public, any way to prefix them >> with __stdcall? That would allow .NET to use the callbacks also [1], >> [2], with the only solution I've seen in [3] that is not practical. >> > >> > It would mean having to add something like WINAPI to the header >> file for the typedefs and if we're compiling on Windows then set it >> to __stdcall (note for 64-bit this is ignored anyway and everything >> is __fastcall). >> > >> > e.g. >> > #if defined(WIN32) >> > #define WINAPI __stdcall >> > #else >> > #define WINAPI >> > #endif >> > >> > Note, you can't do that for the existing APIs, because that would >> cause breakage. >> > >> > I haven't tested on Linux with Mono/dotnet, but I assume here one >> doesnt need to worry. >> >> >> >>> On May 25, 2017, at 9:44 AM, Joseph Southwell >> <jsouthwell@xxxxxxxxxxxxx <mailto:jsouthwell@xxxxxxxxxxxxx>> wrote: >> >>> >> >>> This patch allows you to replace the calls to send and recv with >> alternate callbacks. I am using this because I am running an event >> driven network stack with stackfull coroutines in c++. This makes the >> whole thing appear blocking to libssh while still sharing threads >> efficiently. Socket closure is non blocking so I did not add a >> callback for that but if somebody wanted to extend this to work with >> something that isn’t really sockets they would need to add a close >> callback as well since ssh_disconnect calls close on the socket fd. >> >>> <0001-got-external-io-working-in-libssh-client.patch> >> >> >> > [1] https://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx >> <https://msdn.microsoft.com/en-us/library/aa288468%28v=vs.71%29.aspx> >> > [2] https://msdn.microsoft.com/en-us/library/ektebyzx.aspx >> > >> [3] https://www.codeproject.com/Articles/12512/Using-the-CDECL-calling-convention-in-C-changing >> > >
Re: Support external recv and send callbacks | Joseph Southwell <jsouthwell@xxxxxxxxxxxxx> |
Support external recv and send callbacks | Joseph Southwell <jsouthwell@xxxxxxxxxxxxx> |
Re: Support external recv and send callbacks | Joseph Southwell <jsouthwell@xxxxxxxxxxxxx> |
Re: Support external recv and send callbacks | Jason Curl <jason@xxxxxxxxxxxxxxxxxxxxxxxx> |
Re: Support external recv and send callbacks | Joseph Southwell <jsouthwell@xxxxxxxxxxxxx> |
RE: Support external recv and send callbacks | Jason Curl <jason@xxxxxxxxxxxxxxxxxxxxxxxx> |
Re: Support external recv and send callbacks | Joseph Southwell <jsouthwell@xxxxxxxxxxxxx> |