Access OSCall>>getLastError after an async call

[Neil Morrison]

We are trying to improve some error handling after calling into a Windows OS API.
As per usual gives you a 0/1 for success/failure and then you use the getLastError to find out what happend.

This mechanism works fine for inline calls but never gives a value when using asyncCalls. Can understand this - different threads etc maybe!

I've been trying to discover if there is a way to determine this value from an asyncCall?

Thanks

Neil Morrison

Principal Developer
Royal New Zealand Police

[Henry Johansen]

If you load OpenSSL, and look at senders of lockThreadIn: , I think the OpenSSL dispatcher does the same thing you want, using lockThreadIn: to ensure the SciSslFunctions::SSL_get_error function is called using the same thread as the initial async call. Cheers,

Henry Johansen VAST Consultant Senior Software Engineer  hjoh...@instantiations.com  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/efd08c0e-95a6-4a7a-b1a7-d9234cead399n%40googlegroups.com.

[Neil Morrison]

Hi,

Did some trialling and no joy - but no issue we converted our HTTP Smalltalk code into a library in C++ which handled all the comms processes and dumbed our Smalltalk calls down to pretty a single line to send/receive content. This now means the handling is inside one async platform call and can now determine the OS Last Error situations. Bonus for us we now get a reliable way of handling keep-alive connections and also handling timeout situations properly and from there allow retries.

So, all up win across the board for us - of course some would say "that's not Smalltalk" and I concur but we have 28yrs of Smalltalk investment which isn't going away anytime soon so this is merely a better position for us (a fundamental one) and has simplified our communications handling

Thanks,

Neil