On 16 March 2011 02:40, Karl Tomlinson xm...@karlt.net wrote:
Jamey Sharp writes:
So I don't see anything we can do except require that callers meet the
documented requirements for XSetErrorHandler. I did try to find a kludge
to let existing apps survive this bug, but anything I could think
this with the xtrans version of libX11?
I have to pawn this off as a bug in callers.
Why are we spinning in _XReply rather than entering a deadlock here?
It seems to me that we shouldn't wake from this ConditionWait because
the _XReply we're nested in won't ever ConditionBroadcast()... so why
is he
Jamey Sharp writes:
So I don't see anything we can do except require that callers meet the
documented requirements for XSetErrorHandler. I did try to find a kludge
to let existing apps survive this bug, but anything I could think of
probably breaks multi-threaded clients.
Thanks for the
On 03/04/2011 01:20 AM, Karl Tomlinson wrote:
On Thu, 24 Feb 2011 12:27:28 +1300, xm...@karlt.net wrote:
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point
On 03/04/2011 10:32 AM, Rami Ylimäki wrote:
On 03/04/2011 01:20 AM, Karl Tomlinson wrote:
On Thu, 24 Feb 2011 12:27:28 +1300, xm...@karlt.net wrote:
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
On Thu, 24 Feb 2011 12:27:28 +1300, xm...@karlt.net wrote:
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point out a reason why
this now works less
On 02/23/2011 04:35 PM, Michal Suchanek wrote:
X server seems to preserve the extension codes until the server is
regenerated and therefore all connections should use the same codes.
Is that guaranteed by some protocol or does it just happen to work as
the requests in error handler did?
On Fri, Feb 25, 2011 at 03:18:37PM +0200, Rami Ylimäki wrote:
On 02/25/2011 02:48 PM, Daniel Stone wrote:
On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote:
Documentation of C.2.1 XInitExtension from Xlib manual says that
the Xlib specific extension number in XExtCodes is connection
On 02/25/2011 02:48 PM, Daniel Stone wrote:
On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote:
On 02/23/2011 04:35 PM, Michal Suchanek wrote:
X server seems to preserve the extension codes until the server is
regenerated and therefore all connections should use the same codes.
Is
On 25 February 2011 14:39, Daniel Stone dan...@fooishbar.org wrote:
On Fri, Feb 25, 2011 at 03:18:37PM +0200, Rami Ylimäki wrote:
On 02/25/2011 02:48 PM, Daniel Stone wrote:
On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote:
Documentation of C.2.1 XInitExtension from Xlib manual
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point out a reason why
this now works less successfully than previously, then that would
bump up the priority at our end.
By
On 23 February 2011 11:15, Rami Ylimäki rami.ylim...@vincit.fi wrote:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point out a reason why
this now works less successfully than
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point out a reason why
this now works less successfully than previously, then that would
bump up the priority at
On Sat, Jan 29, 2011 at 09:54:37 -0800, Jeremy Huddleston wrote:
2) emacs' error handler seems bugged. Is it legal to call XSync() within the
error handler? It certainly seems like it shouldn't. Did we used to
actually support this with the xtrans version of libX11?
Not as far as I can
On 02/22/2011 11:14 AM, Julien Cristau wrote:
On Sat, Jan 29, 2011 at 09:54:37 -0800, Jeremy Huddleston wrote:
2) emacs' error handler seems bugged. Is it legal to call XSync() within the
error handler? It certainly seems like it shouldn't. Did we used to actually
support this with the
Rami Ylimäki writes:
Today I found out that even Mozilla code is
suffering from this problem
(http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsX11ErrorHandler.cpp).
Adding Karl into CC. It looks like nsX11ErrorHandler.cpp is also
calling Xlib functions resulting in protocol
XSync() within
the error handler? It certainly seems like it shouldn't. Did we used to
actually support this with the xtrans version of libX11?
Why are we spinning in _XReply rather than entering a deadlock here? It
seems to me that we shouldn't wake from this ConditionWait because
On Mon, Feb 21, 2011 at 7:51 PM, Jeremy Huddleston jerem...@apple.com wrote:
So... what should we do about this?
A good first step would be to try come up with a small-ish test case,
or to at least
figure out how to reproduce the problem on another system. I use
EMACS on my RHEL6
and
On Feb 21, 2011, at 19:03, Pat Kane wrote:
On Mon, Feb 21, 2011 at 7:51 PM, Jeremy Huddleston jerem...@apple.com
wrote:
So... what should we do about this?
A good first step would be to try come up with a small-ish test case,
or to at least
figure out how to reproduce the problem on
On Mon, Feb 21, 2011 at 9:38 PM, Jeremy Huddleston jerem...@apple.com wrote:
IDL is a data visualization package used a lot by astrophysicists \
(http://www.ittvis.com/ProductServices/IDL.aspx)
Thanks, I'll take a look at IDL.
Should we actualy support calling _XReply from an error
. Is it legal to call XSync() within the
error handler? It certainly seems like it shouldn't. Did we used to actually
support this with the xtrans version of libX11?
Why are we spinning in _XReply rather than entering a deadlock here? It seems
to me that we shouldn't wake from this ConditionWait
() within the
error handler? It certainly seems like it shouldn't. Did we used to
actually support this with the xtrans version of libX11?
Why are we spinning in _XReply rather than entering a deadlock here? It
seems to me that we shouldn't wake from this ConditionWait because the
_XReply
22 matches
Mail list logo
