HPInc / HP-Digital-Microfluidics

HP Digital Microfluidics Software Platform and Libraries
MIT License
2 stars 0 forks source link

Get rid of `post_result` arguments #183

Open EvanKirshenbaum opened 5 months ago

EvanKirshenbaum commented 5 months ago

All of the Operation and StaticOperation scheduling methods take a post_result method that's used to specify whether or not the caller wants the result posted to Delayed object that's the return value. The original thought was that there would be situations in which you just wanted the operation to happen, but you didn't care about the value and you didn't need to sequence something else after it, and I was worried that posting the value and looking for callbacks would be an unnecessary expense worth pruning.

Looking at the actual code:

    def post(self, val: Tcontra) -> None:
        assert not self.has_value
        self._val = (True, val)
        lock = self._maybe_lock
        if lock is not None:
            with lock:
                for fn in self._callbacks:
                    fn(val)
                # Just in case this object gets stuck somewhere.
                # The callbacks are never going to be needed again
                del self._callbacks

I'm not sure why I bothered. If we really don't need the value, then nobody's tried to add a callback, and all we have is

  1. constructing a tuple and setting it as _val,
  2. checking _maybe_lock,
  3. noticing that it's None.

That's almost certainly less work than we're doing passing around post_result. And just letting it happens means that the caller can't be wrong about passing in post_result=False for an operation that actually does use its returned future.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 22, 2022 at 2:48 PM PDT.