Option to block or not block in race_mirai()

[wlandau]

@shikokuchuo, would you be open to a non-blocking mode for race_mirai(), as well as a timeout for the current blocking mode?

The current blocking mode could REALLY simplify crew by getting rid of all its use of manual condition variables (including CV forwarding with %~>%). But I would need to be able to set a timeout (as in nanonext::until_()) in each race_mirai() call so crew could keep running its worker launch loop.

On the other hand, there are completely different parts of crew that could benefit from a non-blocking version of race_mirai(). A non-blocking race_mirai() would let me ditch my clunky optimization with collections::dict() and just trust the speed of race_mirai() (which is excellent).

c.f. #536.

[wlandau]

I suppose a single new timeout argument with the ability to set it to 0 would cover all the use cases I described.

[shikokuchuo]

Noted. nanonext has already shipped so not much I can do in the near term.

The non-blocking option is simply a version of .unresolved() that returns the index?

[wlandau]

Noted. nanonext has already shipped so not much I can do in the near term.

Yeah, sorry I missed the deadline on that.

The non-blocking option is simply a version of .unresolved() that returns the index?

That returns the index if resolved, yes.

[shikokuchuo]

Hi @wlandau I was in the process of implementing this when I realised that there's a better general concurrency pattern for what you want.

In short, you supply a 'control' aio, where you set the timeout as the [first] index, and then if that is returned then you know you've timed out.

s <- nanonext::socket()
library(mirai)
daemons(2)
m <- mirai(Sys.sleep(10))
idx <- race_mirai(list(recv_aio(s, timeout = 1000L), m))
idx
#> [1] 1

This is a bit more boilerplate, but is genuinely a more useful pattern than an ad hoc 'timeout' argument to race_mirai(). The example above uses a bare nanonext aio from an unconnected socket, which is as lightweight as can be.

Ultimately it would be inconsistent for race_mirai() to have a 'timeout' argument as it's in the same family as call_mirai() and collect_mirai() and neither of them do.

[wlandau]

Oh interesting! Does the protocol of the socket matter?

One puzzling thing is that in the case of a timeout of 0, if I don't create the AIO separately, there seems to be a fraction of a second of overhead. Do you know why that might be? It seems to happen whether the timeout is zero or positive.

library(mirai)
library(nanonext)
daemons(2L)
task <- mirai(Sys.sleep(1000))
socket <- socket(protocol = "bus")

system.time(aio <- recv_aio(socket, timeout = 0))
#>    user  system elapsed 
#>       0       0       0

system.time(race_mirai(list(recv_aio(socket, timeout = 0), task)))
#>    user  system elapsed 
#>    0.02    0.01    0.41

^{Created on 2026-03-02 with reprex v2.1.1}

Session info

sessioninfo::session_info()
#> Warning in system2("quarto", "-V", stdout = TRUE, env = paste0("TMPDIR=", :
#> running command '"quarto"
#> TMPDIR=C:/Users/willl/AppData/Local/Temp/RtmpqUdg24/file50f05b947061 -V' had
#> status 1
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.5.1 (2025-06-13 ucrt)
#>  os       Windows 11 x64 (build 26200)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language (EN)
#>  collate  English_United States.utf8
#>  ctype    English_United States.utf8
#>  tz       America/Indianapolis
#>  date     2026-03-02
#>  pandoc   3.6.3 @ c:\\Program Files\\Positron\\resources\\app\\quarto\\bin\\tools/ (via rmarkdown)
#>  quarto   NA @ c:\\PROGRA~1\\Positron\\RESOUR~1\\app\\quarto\\bin\\quarto.exe
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.5   2025-04-23 [1] CRAN (R 4.5.1)
#>  digest        0.6.37  2024-08-19 [1] CRAN (R 4.5.1)
#>  evaluate      1.0.5   2025-08-27 [1] CRAN (R 4.5.1)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.5.1)
#>  fs            1.6.6   2025-04-12 [1] CRAN (R 4.5.1)
#>  glue          1.8.0   2024-09-30 [1] CRAN (R 4.5.1)
#>  htmltools     0.5.8.1 2024-04-04 [1] CRAN (R 4.5.1)
#>  knitr         1.50    2025-03-16 [1] CRAN (R 4.5.1)
#>  lifecycle     1.0.5   2026-01-08 [1] RSPM (R 4.5.0)
#>  mirai       * 2.6.0   2026-02-13 [1] RSPM (R 4.5.0)
#>  nanonext    * 1.8.0   2026-02-09 [1] RSPM (R 4.5.0)
#>  reprex        2.1.1   2024-07-06 [1] RSPM (R 4.5.0)
#>  rlang         1.1.7   2026-01-09 [1] RSPM (R 4.5.0)
#>  rmarkdown     2.30    2025-09-28 [1] CRAN (R 4.5.1)
#>  sessioninfo   1.2.3   2025-02-05 [1] CRAN (R 4.5.1)
#>  withr         3.0.2   2024-10-28 [1] CRAN (R 4.5.1)
#>  xfun          0.53    2025-08-19 [1] CRAN (R 4.5.1)
#>  yaml          2.3.10  2024-07-26 [1] CRAN (R 4.5.0)
#> 
#>  [1] C:/Users/willl/AppData/Local/R/win-library/4.5
#>  [2] C:/Program Files/R/R-4.5.1/library
#>  * ── Packages attached to the search path.
#> 
#> ──────────────────────────────────────────────────────────────────────────────

Oddly, the 0.2 second overhead below seems to persist whether or not we store the AIO in a variable first.

library(mirai)
library(nanonext)
daemons(2L)
task <- mirai(Sys.sleep(1000))
socket <- socket(protocol = "bus")

system.time(aio <- recv_aio(socket, timeout = 1000))
#>    user  system elapsed 
#>       0       0       0
  
system.time(race_mirai(list(aio, task)))
#>    user  system elapsed 
#>    0.00    0.00    1.21

system.time(race_mirai(list(recv_aio(socket, timeout = 1000), task)))
#>    user  system elapsed 
#>     0.0     0.0     1.2

^{Created on 2026-03-02 with reprex v2.1.1}

Session info

sessioninfo::session_info()
#> Warning in system2("quarto", "-V", stdout = TRUE, env = paste0("TMPDIR=", :
#> running command '"quarto"
#> TMPDIR=C:/Users/willl/AppData/Local/Temp/Rtmps3EBRe/file6234407a2dee -V' had
#> status 1
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.5.1 (2025-06-13 ucrt)
#>  os       Windows 11 x64 (build 26200)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language (EN)
#>  collate  English_United States.utf8
#>  ctype    English_United States.utf8
#>  tz       America/Indianapolis
#>  date     2026-03-02
#>  pandoc   3.6.3 @ c:\\Program Files\\Positron\\resources\\app\\quarto\\bin\\tools/ (via rmarkdown)
#>  quarto   NA @ c:\\PROGRA~1\\Positron\\RESOUR~1\\app\\quarto\\bin\\quarto.exe
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.5   2025-04-23 [1] CRAN (R 4.5.1)
#>  digest        0.6.37  2024-08-19 [1] CRAN (R 4.5.1)
#>  evaluate      1.0.5   2025-08-27 [1] CRAN (R 4.5.1)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.5.1)
#>  fs            1.6.6   2025-04-12 [1] CRAN (R 4.5.1)
#>  glue          1.8.0   2024-09-30 [1] CRAN (R 4.5.1)
#>  htmltools     0.5.8.1 2024-04-04 [1] CRAN (R 4.5.1)
#>  knitr         1.50    2025-03-16 [1] CRAN (R 4.5.1)
#>  lifecycle     1.0.5   2026-01-08 [1] RSPM (R 4.5.0)
#>  mirai       * 2.6.0   2026-02-13 [1] RSPM (R 4.5.0)
#>  nanonext    * 1.8.0   2026-02-09 [1] RSPM (R 4.5.0)
#>  reprex        2.1.1   2024-07-06 [1] RSPM (R 4.5.0)
#>  rlang         1.1.7   2026-01-09 [1] RSPM (R 4.5.0)
#>  rmarkdown     2.30    2025-09-28 [1] CRAN (R 4.5.1)
#>  sessioninfo   1.2.3   2025-02-05 [1] CRAN (R 4.5.1)
#>  withr         3.0.2   2024-10-28 [1] CRAN (R 4.5.1)
#>  xfun          0.53    2025-08-19 [1] CRAN (R 4.5.1)
#>  yaml          2.3.10  2024-07-26 [1] CRAN (R 4.5.0)
#> 
#>  [1] C:/Users/willl/AppData/Local/R/win-library/4.5
#>  [2] C:/Program Files/R/R-4.5.1/library
#>  * ── Packages attached to the search path.
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[shikokuchuo]

Oh I forgot to include signalling the cv for the recvAio, So you'd need something like:

race_mirai(list(recv_aio(socket, timeout = 1000, cv = nextget("cv")), task)

[wlandau]

Nice! This is all perfect for crew. I'll begin the refactor within the next couple weeks.

[wlandau]

As I look at the implementation in crew, I'm actually a bit concerned about how the list(recv_aio(), ...) workaround would scale. This would get called in controller$pop(), which often runs thousands of times a second. I haven't profiled it, but I worry that reconstructing such a large task list this often would worsen performance.

I did think about another workaround to put the recv_aio() object permanently in the task list up front, but then race_mirai() would always return immediately, whereas sometimes crew needs to wait for a user-defined timeout.

@shikokuchuo, is there a different workaround you see?

[wlandau]

The conversion of the controller's task structure to a list is itself problematic because of all the copy-on-modify operations in general (a Chesterton fence I am just remembering I built years ago). Currently crew uses a collections::dict() structure, but I think I could go back to using a hash environment without loss of performance. Adding/modifying the sentinel recv_aio() in the hash environment would be only O(1) time with the number of tasks.