$recv(), deasync or similar

[lurodrigo]

Hi! I just wanted to know if a $recv() method, similar to the ones you see in Python's websockets or websocket-client, is on your plans, or some form of dealing with websockets synchronously. I believe getting data from a websockets API and processing it right after, for example, might be a common use case.

In my case, I needed to get data from an external API, but I couldn't make it work synchronously. I implemented a naïve deasync solution: I made the handlers store data at a list() on my R6 class, created a send method that called ws$send(), and looped over Sys.sleep() until my list was updated (or it took too much time). It didn't work. R kept waiting until my method finished and only then ran the handlers (not really an expert here, but I suspect this might have something to do with the way R handles threads). Suggestions for workarounds would be hugely appreciated :)

I just finished writing a small Python class that does the same (using recv()) and, tomorrow, I will try to integrate it with R using reticulate, but maybe there's a better solution.

Anyway, thanks for your attention!

[alandipert]

Thanks @lurodrigo we'll consider your request. In the meantime, you might think about using promises to get synchronous-looking code:

library(websocket)
library(promises)

msg <- promise(function(resolve, reject) {
  ws <- WebSocket$new("ws://echo.websocket.org/")
  ws$onOpen(function(e) ws$send("hello"))
  ws$onMessage(function(e) resolve(e$data))
})

msg %...>%
  sprintf("Message was: %s", .) %...>%
  print()

[MilesMcBain]

@alandipert motivated by a similar situation (writing test code that needs to make ws calls to chrome deubugger) I am trying to use the pattern you have proposed. I note that resolve is not exported from the promise namespace, will this change in the future?

Edit: Nevermind. I see that it has to be called inside the promise constructor. Eeeep.

[jcheng5]

@lurodrigo In your Sys.sleep() loop, replace Sys.sleep(1) (or whatever) with later::run_now(1L). This isn't a safe technique to use when you're in Shiny, httpuv, or using promises explicitly, but it should work for now if you're using websockets in isolation.

[jcheng5]

Internal note: we should make this work by exposing wsPoll or whatever. The idea being to pump messages for this websocket but nobody/nothing else. This could be exposed as a function that would wait for the next message, or return NULL if a specified timeout was reached, or throw if the socket was closed before a message was received.

Need to discuss whether this makes sense as an extension to the current WebSocket object, or whether it would be better to have a high-level R function that creates a different kind of object. We've had the same idea for a high-level R function that creates a (Shiny) reactive websocket.

[MilesMcBain]

Thanks for the new advice @jcheng5. I tried to implement the approach suggested by @alandipert but since I'm in a testing context at some point I really must know whether the test has failed or passed.

The promise setup worked pretty well in the sense that I found it convenient to say "the promise is resolved when you get a reply matching this pattern". But since the promise code doesn't block my tests return pending promises. To my surprise there seems to be no way to block on a promise as with future::value()?

At any rate wsPoll would be pretty convenient, it would save me writing loops, actually I never do that, it would save me using Recall and potentially blowing up my stack. ;)

[jcheng5]

@MilesMcBain, sorry for the delay in replying. There's no official blocking way to wait for a promise, no; I've done that on purpose. The reason is because a function that blocks while waiting for a promise, would necessarily need to call later::run_now, and thus introduce a "yield point" which is not visible to callers further up the stack. This is a dangerous way to program, mostly if you're doing this in a reusable function or (especially) a package, as it could introduce race conditions that a caller would have no reason to suspect.

That said, it's not dangerous at all if you're just doing this from the R console, a top-level script, or a test. In that case, you can implement your own future::value equivalent as I have in the promises package's own test suite (the function called extract):
https://github.com/rstudio/promises/blob/bdaf754105600bd947ae1db667b19a12acadd127/tests/testthat/common.R#L18-L40

[jangorecki]

is there any documentation on that issue available? or plans to address that? exporting wsPoll?

the most straightforward workaround seems to be just running production scripts by hand which is rather silly