Skip to content

Signal mechanism from daemon to host #544

@shikokuchuo

Description

@shikokuchuo

(This message has been a journey.)

After more research, I cannot find a specific "signal" mechanism so that the R expression can immediately be signaled back to the main host while the rest of the expression continues to execute.

Long-story-short, I enabled daemons(..., output=TRUE) to see errors/warnings immediately, nice that they are passed immediately. I thought they may be passed back to the local process as "condition"s in which case handlers would be able to work on them, but alas I believe they are being merely cat'ed (or equivalent) to the local console.

From this, two questions:

  • Is it possible to tag the remote-output with a particular "condition" where its default local handler is merely cat(cond)? This would continue the current behavior, but would allow a calling handler to deal with remote output distinctly from local output. (If always doing this as a condition is concerning, it could be as an option, something like daemons(.., output=T, output_condition=T).)
  • I see the since-removed .signal= argument which references nanonext::cv(), is cv() applicable here? Is there a way to allow remote signals (distinct from console output) to be caught via the normal R mechanisms?

I'm adding this comment mostly to say that I continue to look into the source to hope to self-answer, but I'm not finding something to lead me to a working solution. Since this discussion has spiraled from unassigned() to a bit more, would it be better as a Discussion?

Originally posted by @r2evans in #540

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions