Add public condition-signalled? procedure for peeking at condition state

[cwebber]

I'm not as sure how you'll feel about this one. This adds the ability to peek inside the atomic box of conditions. It also reuses the name for the atomic box in the publicly available procedure.

Obviously it would be a terrible idea to expose the ability to mutate the value of the condition atomic box, but I've found that peeking at this value could be useful; for example, I have a condition that I use to tell the actor's main loop whether the actor is dead / stop looping, and in a couple of places it's useful to check that without waiting on it. I did add documentation saying that in general you want to use wait/wait-operation though.

[wingo]

Currently (because we currently deterministically go through the sub-operations of a choice in order) this is equivalent to:

(define (condition-signalled? cvar)
  (perform-operation
   (choice-operation
    (wrap-operation (wait-operation cvar) (lambda () #t))
    (wrap-operation (timer-operation 0) (lambda () #f)))))

So I guess this is a performance hack. Can you point to an example of its use?

[cwebber]

Ah! I didn't realize you could do that (or that sub-operations were ordered, which is useful info... but I'm guessing that's not a promise to stay stable?)

The main use case I had was spawning another fiber that was looping on some task as an assistant to an actor, but if the actor died, it may as well die itself.

[cwebber]

I think I'm willing to close this if (assuming the manual doesn't already say it, maybe I missed it) that the manual says that we deterministically go through the sub-operations in order (it's okay to say "this is true for now, but it might not remain true"), and if that changes, also document/announce that clearly. That way I don't feel like I'm relying on a feature that might disappear at any moment.

If you're okay with that, I can even draft up the text in the manual.

[cwebber]

Well, I figured out how to get around it in my code, so I don't need this at the moment. But it would be good to clearly signal if the ordering of choice-operation ever loses the property of being done in order as such!

[cwebber]

One difference that wasn't discussed is that the procedure I provided in the PR could be used outside of a running fibers environment. I guess it's a question of whether that's a feature worth having or if it's too much exposure of internal machinery?

[D4ryus]

Currently (because we currently deterministically go through the sub-operations of a choice in order) ...

I think this is not true as sub-operations of the choice-op are choosen by random (see offset on line 197):

fibers/fibers/operations.scm

Lines 195 to 208 in 28233c0

	(($ <choice-op> base-ops)
	(let* ((count (vector-length base-ops))
	(offset (random count)))
	(let lp ((i 0))
	(if (< i count)
	(match (vector-ref base-ops (modulo (+ i offset) count))
	(($ <base-op> wrap-fn try-fn)
	(match (try-fn)
	(#f (lp (1+ i)))
	(thunk
	(if wrap-fn
	(call-with-values thunk wrap-fn)
	(thunk))))))
	(suspend)))))))

[emixa-d]

How about

(define (try-operation operation)
  "Return #false on failure, or a thunk returning [...] on success."
   ...)

instead? It's more general.