On Apr 29, 2020, at 4:20 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 29 Apr 2020 12:01:24 -0700 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
The call_once() decorator would need different logic:
1) if the function has already been called and result is known, return the prior result :-) 2) if function has already been called, but the result is not yet known, either block or fail :-(
It definitely needs to block.
Do you think it is safe to hold a non-reentrant lock across an arbitrary user function? Traditionally, the best practice for locks was to acquire, briefly access a shared resource, and release promptly.
3) call the function, this cannot be reentrant :-(
Right. The typical use for such a function is lazy initialization of some resource, not recursive computation.
Do you have some concrete examples we could look at? I'm having trouble visualizing any real use cases and none have been presented so far. Presumably, the initialization function would have to take zero arguments, have a useful return value, must be called only once, not be idempotent, wouldn't fail if called in two different processes, can be called from multiple places, and can guarantee that a decref, gc, __del__, or weakref callback would never trigger a reentrant call. Also, if you know of a real world use case, what solution is currently being used. I'm not sure what alternative call_once() is competing against.
6) does not have instrumentation for number of hits 7) does not have a clearing or reset mechanism
Clearly, instrumentation and a clearing mechanism are not necessary. They might be "nice to have", but needn't hinder initial adoption of the API.
Agreed. It is inevitable that those will be requested, but they are incidental to the core functionality. Do you have any thoughts on what the semantics should be if the inner function raises an exception? Would a retry be allowed? Or does call_once() literally mean "can never be called again"? Raymond