Potential go routine on blocking functions

[davidrenne]

In the case of an accidental blocked thread where the calling function has incorrect or bad code:

https://github.com/ably/ably-go/blob/main/ably/realtime_channel.go#L512

An entire set of messages will be blocked forever. Do you think you can add a go routine for this to prevent this? I realize every 1 payload will be a go routine, but perhaps you can call the function callback and timeout to kill the go routine somehow if it doesnt return in a certain number of seconds?

It wasnt inherently obvious that these callbacks are synchronous and thus if I have 1 payload which incorrectly hangs a channel without a select timeout, my entire servers pub sub goes down. Now I have added selects and timeouts if the channel is gone so that these things clear. So hopefully it solves my problem overall, but I saw this code and wanted to have a discussion about strategies or documentation around a blocking function call that can ruin an entire servers pubsub.

[sync-by-unito]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3855

[sacOO7]

Hi @davidrenne we have intentionally kept public methods as blocking in nature.
You might like to read => https://github.com/ably/ably-go/blob/main/UPDATING.md#asynchronous-operations-and-the-context-concurrency-pattern
If you don't want to block on the method call, you can externally cancel the context.
Let me know if more information is needed.

[sacOO7]

This also means, that if you don't want to wait till the call to return, you have to implement your own mechanism to handle success/failure of the operation asynchronously.
I won't recommend spawning new goroutine for every method call, because creating threads still is an expensive operation and should be managed as a threadpool ( pool of limited threads ).
You might like to check https://betterprogramming.pub/building-and-testing-a-worker-pool-in-go-bce4c6da4431

[sacOO7]

@davidrenne let us know if you have any updates on this, otherwise, we will close the issue