Asynchronous callbacks?

[Danp2]

I've seen where attempts to perform asynchronous callbacks yield undesirable results. For example --

I've experienced similar results with my attempts to use asynchronous callbacks to implement websockets. Looking at the documentation, there isn't any indication that DllCallbackRegister is limited to synchronous operations only. However, there is @Melba23's comment here from 10 years ago.

This appears to be a timing issue because the callback will often occur properly without causing a crash. Does anyone know if this the developers have looked into this to see if it can be fixed?

 

[mLipok]

This question should be asked to @jpm or @Jon.
Hope they found some spare time to look here and in the code to answer your question.
Be patient.

[jpm]

Hi,

thanks for puting some work on the table,

If you want we look at it please open a ticket with a repro script

Cheers

[Danp2]

Hi @jpm

See https://www.autoitscript.com/trac/autoit/ticket/3952. The comments contain the link to the required DLL because it was too big to upload.

Thanks for taking a look at this!

Dan

[jpm]

Thanks, Iwas not seing it was related with ticket #3952

Not sure I can find the solution 

Cheers

[Danp2]

On 4/19/2023 at 12:27 AM, jpm said:

Not sure I can find the solution 

Were you able to reproduce the crash with the provided script?

[jpm]

I need some time to work on it

I will report ASAP

[LarsJ]

This is a performance issue. Optimize the _WS_Send() function in WebSocketAsio.au3 this way:

Func _WS_Send($sData)
  Return DllCall($hWEBSOCKDLL, $c_ret_size_t, "websocket_send", "wstr", $sData, "USHORT", StringLen($sData), "BOOL", 0)[0]
EndFunc

Other functions involved in asynchronous callback must be similarly optimized.

Also remove the Sleep(10) line in the For loop in reproduce.au3.

It's exactly the same problem as in the Subclassing bug.

[Danp2]

Thanks for the feedback @LarsJ and also for linking to the prior discussion. @jpm I'm guessing that this is the old Trac ticket.

Confused as to why this isn't considered a bug. 🤔

[mLipok]

4 minutes ago, Danp2 said:

Confused as to why this isn't considered a bug.

It waited for confirmation. Finally @jpm closed this ticket due to no response.

Edited April 24, 2023 by mLipok

[Danp2]

@mLipok Yes, I read / understand that. I will be testing the suggested "workaround", but I hope the dev team will take another look at this issue.

[jpm]

The workaround fail if more loop 100 to  10000.

I will leave the final answer to @Jon as it is beyond my competence.

Suppressing all consolewrite will produce error

[Danp2]

57 minutes ago, jpm said:

The workaround fail if more loop 100 to  10000.

That is what I was suspecting would happen.

I've seen a few instances (here and here) where callbacks have been simulated using Windows messaging, and I'm likely going to try this out.

[Danp2]

@Janeer Does this method still utilize DllCallbackRegister? I'll need to do some research to understand this approach.

[mLipok]

@Janeer good first post 👍

EDIT Jos: Pity it was a placeholder for spam.  

 2️⃣4️⃣um

Edited May 4, 2023 by Jos

[Nine]

I have done quite a bit of asynchronous events (see my signature) or should we call it overlapped callback.  I do not know if this is something you would need.  But I think this is what @Janeer was talking about.

[Danp2]

@Nine I don't know if any of the items in your signature would help. I simply need to be able to perform an asynchronous callback from a DLL without causing AutoIt to crash.

[jpm]

Thinking about the pb, I think that the serialisation of the callback code must me handle inside the callback.

I am almost sure that execution of a new callback, the previous one not completely handled, will produce conflict

Good luck with the @Janeer proposal which look to me very sensible

[argumentum]

...so, wassup with @Janeer and @Janiir ?  same one ? 1st post missing and same or similar 1st post ? 

[Danp2]

Yes, they are very likely one and the same. The first post from @janeer was deleted due to spam that was added during an edit of the original post. Chances are that @Janiir will meet the same fate.