Add execute-task to execute task and discard return value

[tmccombs]

This allows you to schedule a task without the overhead of needing to keep track of the return value.

[jorams]

I would really like to see this merged. Right now I'm running a special worker just to keep the channel from accumulating endless amounts of return values.

[deadtrickster]

@jorams Something like this also works

(lparallel.kernel::submit-raw-task
   (lparallel.kernel::make-task-instance
    (lambda ()
      (apply handler args))
    :cl-events)
   *kernel*)

[tmccombs]

@deadtrickster but you have to use non-exported functions in that. And my change basically just exports a function that does that.

[lmj]

Sorry for the delay. I think this is a good idea, though I'd prefer a name that makes it clearer what is happening -- maybe submit-untracked-task or submit-unchanneled-task or submit-task/no-channel? I'm open to suggestions. There could also be a trivial wrapper macro to match future syntax.

[lmj]

I think I would go with submit-bare-task. There are complications with error handling which remind me that I've visited this issue before. The transfer-error restart, which is bound at the start of each worker, can't transfer an error since there is no channel. Hiding the restart inside a bare task seems like a bad idea because the user probably expects *debug-tasks-p* and (task-handler-bind ((error #'invoke-transfer-error)) ...) to work with bare tasks. Thus transfer-error should stay, yet not do what it is advertised to do. I suppose we tell users that in the context of a bare task transfer-error means transfer to oblivion.

[luismbo]

Random idea (that might give better ideas to someone else or make submit-bare-task look even better): submit-task-and-forget.

[mdbergmann]

Can't just a future be used for that purpose?

[tmccombs]

A future needs to keep track of the result value. The purpose of this PR is to provide a way to schedule a task without needing the overhead of keeping the result value.

[mdbergmann]

In Java/Scala you can define a future like Future[Unit] which basically is a future without result.

Anyway. I don't want to interfere with this PR. What's keeping it from getting merged?

[sabracrolleton]

What is keeping this from being merged?

[MonadMania]

Yes, I also want this behavior. I don't want to have to purge the channel of unwanted return values. Is anyone managing this repo? It looks dead.