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