hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/11/20 5:31 AM, jr wrote:
> > have still not seen any "hangs", but managed to get an error; ...
>
> Thanks.

(I think I might have heard you <sigh>.  :-))

> I've not done any animations with the x11 display. I'll try it
> myself later today. I'd make a moderate bet from your output it's again
> the architectural problem of x11/sdl* not being at the top thread-wise,
> so to speak.

thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
after the initialisation, just bracketing the worker thread's call to update the
window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
companion should do, no?


regards, jr.

Post a reply to this message

On 7/11/20 11:04 AM, jr wrote:
...
>> I've not done any animations with the x11 display. I'll try it
>> myself later today. I'd make a moderate bet from your output it's again
>> the architectural problem of x11/sdl* not being at the top thread-wise,
>> so to speak.
> 
> thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
> after the initialisation, just bracketing the worker thread's call to update the
> window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
> companion should do, no?
> 

:-) I suspect you know more than me. I'm no expert with X11, having only 
surfaced hacked now and again on code using X11. At a high level, if we 
have all the locking / unlocking in place to prevent thread safety 
issues while asking x11 to do stuff and visa versa, things would work.
;-)

What I'm testing is what the nice, verbose error message from X 
suggested - XInitThreads. This seems to add lock / unlocks around all 
the x11 interactions. Thus far, it's working(1).

(1) - The other x11 issues routinely seen OK too - so far.

I was able to duplicate your animation / X11 fails easily - thanks 
(without the sigh this time :-)). Start up an animation and then create 
many interrupts by moving the window hitting keys and such and somewhere 
in the first 20 frames - almost always - boom! Having something which 
fails reliably is very useful. I wasn't able to get there with the prior 
SDL1.2 github issues.

I'll run with the x11 display for a few days and we'll see if the 
XInitThreads() fix holds up.

In reading about it, it looks like it's not the efficient approach and 
likely there is additional exposure to hangs where an interrupt 
generating a lock happens elsewhere during a lock introduced by using 
XInitThreads(). The latter particular locks perhaps not strictly necessary.

The underlying issue tangled here, given our current code architecture, 
is the interrupt handing happening in ways that cause a deadlock of 
locks and hence occasional hangs. For users not generating large numbers 
of interface interrupts, I believe such hangs are rare.

Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a 
continuous loop(2) while accepting scene updating input. Re-reading and 
rendering a scene file as edits/updates are made. I think it possible to 
do limited modeling (spline editing say) without jumping up to Blender, 
Moray or whatever tool to do it.

(2) - Similar in behavior to animation today, but where modeling not 
animation is the aim. No image output, just continuous re-rendering of a 
changing scene to the display. Yes, ugly, partial hacks of this can be 
achieved today.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> What I'm testing is what the nice, verbose error message from X
> suggested - XInitThreads. This seems to add lock / unlocks around all
> the x11 interactions. Thus far, it's working(1).
> (1) - The other x11 issues routinely seen OK too - so far.

that man page merits close reading.  it only speaks about 'Xlib', the "client
library", not (the underlying) X (server).  another pertinent man page, re the
event/interrupt issues snipped from below, is 'XIfEvent(3)'.  my understanding
(from somewhat dim, 20+ years old memory) is that whenever the window "object"
is accessed, you'll need some kind of mutex/XLockDisplay guard arrangement,
still.

another "rant" re "nice, verbose error message".  a few days ago, in an email,
needed to ask what the person (also an Ubuntu user, as it happens) got in reply
when executing "$ which badname", since "badname" did not seem to work.  answer:
"nothing (an empty line)".  the default behaviour for 'which' is to print (to
stderr) a message like "which: no badname in ($PATH)".  what I do not understand
is why the Ubuntu maintainers expend "man-hours"/time + effort on making s/ware
_less_ informative, and therefore less valuable, to the user.  (it sort of
boggles the mind, and that's before the "conspiracy" paranoia kicks in!  :-))

> ...
> Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a
> continuous loop(2) while accepting scene updating input. Re-reading and
> rendering a scene file as edits/updates are made. I think it possible to
> do limited modeling (spline editing say) without jumping up to Blender,
> Moray or whatever tool to do it.

a "hacked" Tclsh?!  ;-)  like the idea though, to be able to interactively build
up scenes would be way cool.


regards, jr.

Post a reply to this message