Documentation Suggestions

[shikokuchuo]

Prework

• [x] Read and agree to the Contributor Code of Conduct and contributing guidelines.
• [x] If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.
• [ ] For any problems you identify, post a minimal reproducible example like this one so the maintainer can troubleshoot. A reproducible example is:
  • [ ] Runnable: post enough R code and data so any onlooker can create the error on their own computer.
  • [ ] Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
  • [ ] Readable: format your code according to the tidyverse style guide.

Description

On the docs, a couple of things I came across re. mirai:

1. https://github.com/wlandau/crew/blob/cb976e035d3b0b4a9f4e00f7e5ba2448153c3d80/R/crew_launcher.R#L43 The argument name is 'timerstart'.

2. https://github.com/wlandau/crew/blob/cb976e035d3b0b4a9f4e00f7e5ba2448153c3d80/R/crew_launcher.R#L33 Suggest: (when a worker exits after reaching a timeout or having completed a certain number of tasks) As (i) there is no exit signal and (ii) if for example daemons(0) closes the socket on the client side, the exit is immediate with no linger.

3. The current default for seconds_exit of 0.1 is quite low and could be problematic for sending/receiving large objects. The default in mirai has been 1000 ms = 1L for the past couple of builds. I'd assume this might only be an issue re. autoscaling, but I'd take the performance hit for the extra safety.

[wlandau]

Thanks for explaining, and especially for catching the low default for seconds_exit. Should all be fixed now. With the new seconds_exit, I am going to retest for hanging just in case it helped that particular issue.