On 2018-08-27 17:54, John Snow wrote:
>
>
> On 08/25/2018 09:05 AM, Max Reitz wrote:
>> On 2018-08-22 23:52, John Snow wrote:
>>>
>>>
>>> On 08/22/2018 07: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:
>
On 08/25/2018 09:05 AM, Max Reitz wrote:
> On 2018-08-22 23:52, John Snow wrote:
>>
>>
>> On 08/22/2018 07: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
-
On 2018-08-22 23:52, John Snow wrote:
>
>
> On 08/22/2018 07: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
>>>
On 08/22/2018 07: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
>>
>>
On 2018-08-22 13:43, Max Reitz wrote:
[...]
> 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
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.
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.
