* block_input for some APIs
@ 2016-12-12 18:01 Eli Zaretskii
2016-12-12 21:08 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2016-12-12 18:01 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 18:01 block_input for some APIs Eli Zaretskii
@ 2016-12-12 21:08 ` Paul Eggert
2016-12-12 21:48 ` Stefan Monnier
2016-12-13 3:43 ` Eli Zaretskii
0 siblings, 2 replies; 7+ messages in thread
From: Paul Eggert @ 2016-12-12 21:08 UTC (permalink / raw
To: Eli Zaretskii, emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 21:08 ` Paul Eggert
@ 2016-12-12 21:48 ` Stefan Monnier
2016-12-12 21:53 ` Daniel Colascione
2016-12-13 0:13 ` YAMAMOTO Mitsuharu
2016-12-13 3:43 ` Eli Zaretskii
1 sibling, 2 replies; 7+ messages in thread
From: Stefan Monnier @ 2016-12-12 21:48 UTC (permalink / raw
To: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 21:48 ` Stefan Monnier
@ 2016-12-12 21:53 ` Daniel Colascione
2016-12-13 3:46 ` Eli Zaretskii
2016-12-13 0:13 ` YAMAMOTO Mitsuharu
1 sibling, 1 reply; 7+ messages in thread
From: Daniel Colascione @ 2016-12-12 21:53 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 21:48 ` Stefan Monnier
2016-12-12 21:53 ` Daniel Colascione
@ 2016-12-13 0:13 ` YAMAMOTO Mitsuharu
1 sibling, 0 replies; 7+ messages in thread
From: YAMAMOTO Mitsuharu @ 2016-12-13 0:13 UTC (permalink / raw
To: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 21:08 ` Paul Eggert
2016-12-12 21:48 ` Stefan Monnier
@ 2016-12-13 3:43 ` Eli Zaretskii
1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2016-12-13 3:43 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: block_input for some APIs
2016-12-12 21:53 ` Daniel Colascione
@ 2016-12-13 3:46 ` Eli Zaretskii
0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2016-12-13 3:46 UTC (permalink / raw
To: Daniel Colascione; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-12-13 3:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-12 18:01 block_input for some APIs Eli Zaretskii
2016-12-12 21:08 ` Paul Eggert
2016-12-12 21:48 ` Stefan Monnier
2016-12-12 21:53 ` Daniel Colascione
2016-12-13 3:46 ` Eli Zaretskii
2016-12-13 0:13 ` YAMAMOTO Mitsuharu
2016-12-13 3:43 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.