From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp21.mail.ru (smtp21.mail.ru [94.100.179.250])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 6A7C0401A40
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 24 Oct 2019 22:47:57 +0300 (MSK)
References: <6d69f49ae7d4a58dfef92a654b0c6341df3f0344.1568152663.git.v.shpilevoy@tarantool.org>
 <20191024002155.6tn2b2zrju7wmi2n@tkn_work_nb>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <f49ce585-eee9-d3bf-e1d8-41d0a68e0e14@tarantool.org>
Date: Thu, 24 Oct 2019 21:53:17 +0200
MIME-Version: 1.0
In-Reply-To: <20191024002155.6tn2b2zrju7wmi2n@tkn_work_nb>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH 1/1] app:
 exit gracefully when a main script throws an error
List-Id: Tarantool development <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org

Hi!

On 24/10/2019 02:21, Alexander Turenko wrote:
> I know, the patch was already pushed, but I looked on it briefly anyway.
> 

If something is wrong, it may be fixed as a follow up.

> It is LGTM, however I have one question: see below.
> 
> WBR, Alexander Turenko.
> 
>> @@ -678,6 +686,12 @@ tarantool_lua_run_script(char *path, bool interactive,
>>  		ev_run(loop(), 0);
>>  	/* The fiber running the startup script has ended. */
>>  	script_fiber = NULL;
>> +	/*
>> +	 * Result can't be obtained via fiber_join - script fiber
>> +	 * never dies if os.exit() was called. This is why diag
>> +	 * is checked explicitly.
>> +	 */
>> +	return diag_is_empty(diag_get()) ? 0 : -1;
> 
> This is the only part I'm a bit tentative: can the diagnostic area be
> populated by a user somehow? I tried to do--
> 
>  | fio.open('non_existent', {'O_RDONLY'})
>  | os.exit()
> 
> --in the main script and it seems that it uses some other diagnostic
> area, because the fio error was not reported as the main script fail.

Should it have been reported?

Talking of why it is not now - well, yes, it uses another diagnostics
area. tarantool_lua_run_script() starts a special fiber to run a
script or a console. And the error is forwarded to the main fiber
only when the script fiber does it voluntary, in the end of
run_script_f().

In case of os.exit() the script fiber never finishes, and therefore
never moves its diag to the main fiber. Os.exit() breaks event loop
and freezes the current fiber. It makes ev_run() return in
tarantool_lua_run_script(). After that we see that the diag is empty,
because the script fiber never got to the point of filling it.

> 
> So, things seems to work good, but I didn't got how exactly.
>