Re: Support external recv and send callbacks

[Joseph Southwell <jsouthwell@xxxxxxxxxxxxx>]

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> 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> 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
> [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
>