block_input for some APIs

block_input for some APIs

[Eli Zaretskii]

Does anyone remember why we block input around calls to functions like
getpwnam or tzset or fwrite?

I understand why we do that when we mess with stuff related to the
window-system or the window manager, but why do the above function
need that protection?

TIA

Re: block_input for some APIs

[Paul Eggert]

On 12/12/2016 10:01 AM, Eli Zaretskii wrote:
> Does anyone remember why we block input around calls to functions like
> getpwnam or tzset or fwrite?

I think this dates back to when C-g and/or other handlers called 
longjmp. Since getpwname etc. are not async-signal-safe we needed to 
block input around them, so that C-g's effects were deferred until these 
functions returned. If I'm right, we don't need to block input around 
them any more, since our signal handlers are safer now.

Similarly for MALLOC_BLOCK_INPUT; we should be able to get rid of its 
machinery now.

Re: block_input for some APIs

[Stefan Monnier]

>> Does anyone remember why we block input around calls to functions like
>> getpwnam or tzset or fwrite?
> I think this dates back to when C-g and/or other handlers called
> longjmp.

I'm not completely sure, but my own impression is that this dates back
to before SYNC_INPUT, i.e. with input became available, we'd get an IO
signal and in the handler we'd run a whole bunch of code, since
reentrance was a big issue.  Nowadays we delay this async processing to
the next QUIT so there's no re-entrance issue any more.


        Stefan

Re: block_input for some APIs

[Daniel Colascione]

On Mon, Dec 12 2016, Stefan Monnier wrote:
>>> Does anyone remember why we block input around calls to functions like
>>> getpwnam or tzset or fwrite?
>> I think this dates back to when C-g and/or other handlers called
>> longjmp.
>
> I'm not completely sure, but my own impression is that this dates back
> to before SYNC_INPUT, i.e. with input became available, we'd get an IO
> signal and in the handler we'd run a whole bunch of code, since
> reentrance was a big issue.  Nowadays we delay this async processing to
> the next QUIT so there's no re-entrance issue any more.

That said, the existing calls to block_input don't do a lot of harm, so
there's no need to remove them.

Re: block_input for some APIs

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 12 Dec 2016 16:48:53 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> Does anyone remember why we block input around calls to functions like
>>> getpwnam or tzset or fwrite?
>> I think this dates back to when C-g and/or other handlers called
>> longjmp.

> I'm not completely sure, but my own impression is that this dates back
> to before SYNC_INPUT, i.e. with input became available, we'd get an IO
> signal and in the handler we'd run a whole bunch of code, since
> reentrance was a big issue.  Nowadays we delay this async processing to
> the next QUIT so there's no re-entrance issue any more.

I added some of them around early 2007, when SYNC_INPUT was not used
by default.  These functions call malloc etc. internally (at least on
Darwin), so it was not safe to call read_socket_hook, which also calls
malloc etc., from SIGIO/SIGALRM handler while processing getpwnam etc.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: block_input for some APIs

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 12 Dec 2016 13:08:45 -0800
> 
> On 12/12/2016 10:01 AM, Eli Zaretskii wrote:
> > Does anyone remember why we block input around calls to functions like
> > getpwnam or tzset or fwrite?
> 
> I think this dates back to when C-g and/or other handlers called 
> longjmp.

Right, that was my guess as well.  Thanks.

> If I'm right, we don't need to block input around them any more,
> since our signal handlers are safer now.
> 
> Similarly for MALLOC_BLOCK_INPUT; we should be able to get rid of its 
> machinery now.

Yes, I think it would be good to get rid of those of them we don't
need any longer.

Re: block_input for some APIs

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 12 Dec 2016 13:53:33 -0800
> Cc: emacs-devel@gnu.org
> 
> That said, the existing calls to block_input don't do a lot of harm, so
> there's no need to remove them.

They make the code trickier to read and understand, because
block_input, unblock_input, and input_blocked_p are not thread-safe.
It took me a while to convince myself they are not an issue with the
current concurrency design, except in xgselect.c, and I'm still not
sure my conclusion is 100% valid.