Re: Suspicious error in GTk

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> While trying out SYNC_INPUT with Gtk together with the `eassert' debugging
>> I bumped into the appended backtrace, right at startup.  Basically, the code
>> run from XTread_socket (run asynchronously at any time) can call
>> update_frame_tool_bar which in turn calls xpm_load which ends up calling
>> encode_coding_string (to encode the file's name) which fiddles with
>> specpdl_ptr (via record_unwind_protect) and may run elisp code.
>> 
>> Most likely it will usually not lead to any problem, but I believe it'll
>> bite every now and then and will be difficult to trace.

AFAICT my bug report has nothing to do with alloc.c.  I even believe it's
got nothing to do with SYNC_INPUT.  I just happened to bump into it with
a SYNC_INPUT build (because all my builds use SYNC_INPUT).

> ISTR that parts of alloc.c are carried out inside BLOCK_INPUT, but
> only if SYNC_INPUT is off.

This is an optimization: if SYNC_INPUT is used, we never use malloc inside
a signal handler, so we don't need to wrap them with BLOCK_INPUT.

> Does this mean that we need BLOCK_INPUT even when SYNC_INPUT is on?

I'm not sure what "this" refers to.


        Stefan