Re: [Qemu-devel] [PATCH 3/7] jobs: add exit shim

[John Snow]

On 08/22/2018 06:01 PM, Eric Blake wrote:
> On 08/22/2018 06:43 AM, Max Reitz wrote:
>> On 2018-08-17 21:04, John Snow wrote:
>>> All jobs do the same thing when they leave their running loop:
>>> - Store the return code in a structure
>>> - wait to receive this structure in the main thread
>>> - signal job completion via job_completed
>>>
>>> Few jobs do anything beyond exactly this. Consolidate this exit
>>> logic for a net reduction in SLOC.
>>>
> 
>> OK, so that's that.  Now that I know what it's for, I'd like to ask for
>> a different name.  exit() means kill the process.  JobDriver.exit() will
>> not mean kill the job.  That's where I get a headache.
>>
>> This function is for allowing the job to carry out global qemu state
>> modifications in the main loop.  Neither is that exiting in the sense
>> that the job is destroyed (as this is done only later, and the job gets
>> to take part in it through the transactional callbacks, and .free()),
>> nor is it exiting in the sense that the job needs to do all
>> pre-transactional clean-ups here (they are supposed to do that in .run()
>> -- *unlees* something needs the main loop).
>>
>> I'd like .main_loop_settle().  Or .main_loop_post_run().  I think it's
>> OK to have names that aren't as cool and tense as possible, when in
>> return they actually tell you what they're doing.  (Sure,
>> .main_loop_post_run() sounds really stupid, but it tells you exactly
>> when the function is called and what it's for.)
>>
>> (Maybe the problem of all your naming woes really is just that you
>> always try to find a single word that describes what's going on :-) -- I
>> don't want to go into ProblemSolveFactoryObserverFactorySingleton
>> either, but it's OK to use an underscore once in a while.)
> 
> Does .wrapup or .conclude work any better than .exit for such a one-word
> name that goes away in the next series?  Actually, your suggestion of
> .settle seems reasonable to me (if we want terser than
> .main_loop_settle, because the name is going away, but still have a name
> that is not as weird as '.exit' when there are more steps still to follow)
> 

This is running away from me :)

.exit() goes away after part two of the series, once I refactor all of
these completion functions into their .prepare/.abort/.commit/.clean
components.

It's just important that I do this series ***FIRST***, to avoid
deadlocks in the component callbacks.

--js