2005-02-28 kl. 15.49 skrev Richard Stallman:
This sounds like normally only the main thread should ever be
touching
interrupt_input_blocked, unless we have a bug. Correct? So we
need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread
"Jan D." <[EMAIL PROTECTED]> writes:
>> You wish.
>
> No. I know. The only way the other threads can call xmalloc is if a
> signal handler is called in a non-main thread and then calls xmalloc.
> This should not happen, but if it does there is a bug somewhere.
>>
>
>> I am putting appropriate ass
"Jan D." <[EMAIL PROTECTED]> writes:
But xmalloc and all related routines use BLOCK_INPUT nevertheless.
So
it is obvious that although malloc seemingly can be used (given
_BOTH_
PTHREAD and GTK) without problems, all uses of xmalloc still are
flawed in the old way.
So we still can't allow using
"Jan D." <[EMAIL PROTECTED]> writes:
>> But xmalloc and all related routines use BLOCK_INPUT nevertheless. So
>> it is obvious that although malloc seemingly can be used (given _BOTH_
>> PTHREAD and GTK) without problems, all uses of xmalloc still are
>> flawed in the old way.
>>
>> So we still c
But xmalloc and all related routines use BLOCK_INPUT nevertheless. So
it is obvious that although malloc seemingly can be used (given _BOTH_
PTHREAD and GTK) without problems, all uses of xmalloc still are
flawed in the old way.
So we still can't allow using xmalloc except in the main thread. Wha
"Jan D." <[EMAIL PROTECTED]> writes:
>> "Jan D." <[EMAIL PROTECTED]> writes:
>>
This sounds like normally only the main thread should ever be
touching
interrupt_input_blocked, unless we have a bug. Correct? So we need
not think about how to synchronize accesses to the va
"Jan D." <[EMAIL PROTECTED]> writes:
This sounds like normally only the main thread should ever be
touching
interrupt_input_blocked, unless we have a bug. Correct? So we need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread except the main thread w
"Jan D." <[EMAIL PROTECTED]> writes:
>>
>> This sounds like normally only the main thread should ever be touching
>> interrupt_input_blocked, unless we have a bug. Correct? So we need
>> not think about how to synchronize accesses to the variable, but
>> rather make sure that no thread except th
This sounds like normally only the main thread should ever be touching
interrupt_input_blocked, unless we have a bug. Correct? So we need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread except the main thread will ever run
code
"Jan D." <[EMAIL PROTECTED]> writes:
>>
>> This sounds like normally only the main thread should ever be touching
>> interrupt_input_blocked, unless we have a bug. Correct? So we need
>> not think about how to synchronize accesses to the variable, but
>> rather make sure that no thread except th
This sounds like normally only the main thread should ever be touching
interrupt_input_blocked, unless we have a bug. Correct? So we need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread except the main thread will ever run
code touching it. Corre
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> elusive is going on here. I'll probably have to implement some kind
>> of trace buffering for interrupt_input_block in order to get a hold of
>> what is happening here.
>
> If for some reason you think the problems you're experience have something
> t
David Kastrup <[EMAIL PROTECTED]> writes:
> This sounds like normally only the main thread should ever be touching
> interrupt_input_blocked, unless we have a bug. Correct? So we need
> not think about how to synchronize accesses to the variable, but
> rather make sure that no thread except the
> elusive is going on here. I'll probably have to implement some kind
> of trace buffering for interrupt_input_block in order to get a hold of
> what is happening here.
If for some reason you think the problems you're experience have something
to do with interrupt_input_block, maybe you should tr
"Jan D." <[EMAIL PROTECTED]> writes:
>> "Jan D." <[EMAIL PROTECTED]> writes:
>>
>>> If you configured with GTK, there is a possibility that multiple
>>> threads are updating interrupt_input_block. I've tried to handle that
>>> situation, but bugs may of course still remain.
>>
>> How did you try
"Jan D." <[EMAIL PROTECTED]> writes:
>> Also with regard to the other report you answered (where I was wrong):
>> I might well be mistaken. I am just trying to get a hold of why Emacs
>> keeps crashing on me. It appears, anyway, that something seriously
>> elusive is going on here. I'll probabl
"Jan D." <[EMAIL PROTECTED]> writes:
Also with regard to the other report you answered (where I was
wrong):
I might well be mistaken. I am just trying to get a hold of why
Emacs
keeps crashing on me. It appears, anyway, that something seriously
elusive is going on here. I'll probably have to i
Also with regard to the other report you answered (where I was wrong):
I might well be mistaken. I am just trying to get a hold of why Emacs
keeps crashing on me. It appears, anyway, that something seriously
elusive is going on here. I'll probably have to implement some kind
of trace buffering f
Richard Stallman <[EMAIL PROTECTED]> writes:
> /* Unblock input if we enter with input blocked. This may happen if
>redisplay traps e.g. during tool-bar update with input blocked. */
> while (INPUT_BLOCKED_P)
> UNBLOCK_INPUT;
>
> return Fthrow (Qtop_level, Qnil);
/* Unblock input if we enter with input blocked. This may happen if
redisplay traps e.g. during tool-bar update with input blocked. */
while (INPUT_BLOCKED_P)
UNBLOCK_INPUT;
return Fthrow (Qtop_level, Qnil);
}
This approach of unblocking input appears
Hello, in keyboard.c there is the following code:
DEFUN ("top-level", Ftop_level, Stop_level, 0, 0, "",
doc: /* Exit all recursive editing levels. */)
()
{
#ifdef HAVE_X_WINDOWS
if (display_hourglass_p)
cancel_hourglass ();
#endif
/* Unblock input if we enter with input bloc
21 matches
Mail list logo
