[Bf-committers] Pretty clueless Linux threads crashing...

[Toni Alatalo]

On Friday 24 February 2006 14:21, Ton Roosendaal wrote:
> directly. That's also used by yafray btw... my impression is that SDL
> (S is for Simple!) is mostly used for basic and simple programs, to
> quickly get an app running.

just to rephrase that a bit for the record (Ton you can just skip this email, 
nothing new here :); it is stable and reliable for the things that it is 
mostly used: cross-platform access to display surfaces, opengl 
initialization, and reading keyboard & mouse input. so i can trust it to give 
me a display surface and input events reliably in production apps (we are 
using it in some installation things, and many games and media players etc 
use it)

i dont know if the threading part is much used, but like you said on irc, 
mostly for simple cases (like playing the background music of a game in a 
separate thread than the game itself - e.g. pygame does that). i did not even 
consider using sdl threads even in sdl apps that needed to make multithreaded 
(last year).

but yah, am also hoping that using phtreads directly will solve the 
yet-mysterious behaviour.

> -Ton-

~Toni

>
> On 24 Feb, 2006, at 14:11, Ed Halley wrote:
> > The 'volatile' keyword is best used for situations that proper thread
> > coding cannot fix:  e.g., device drivers which change memory contents
> > within the reach of your process without any notification.  It's an
> > abomination but hardware makers often don't consider software
> > engineering constraints.
> >
> > The proper way to code threads that access the same variables (reading
> > OR writing) is to use the appropriate semaphor/mutex/spinlock
> > mechanism provided by your language and platform.  It doesn't matter
> > if they're global, heaped, stacked or buried within some arcane
> > database API. Minimize the number of variables or objects which must
> > be read while any thread has the possibility of writing them.
> > Consider those variables to be "resources" which must be checked out
> > like a library book, and properly lock them during every write and
> > every read.  (Some people try to get away with locking during reading
> > only, but unless you know your platform will write the whole variable
> > atomically, it's a recipe for disaster to read things without
> > locking.)
> >
> > Every shared variable.  Every shared object.
> >
> > Ton Roosendaal wrote:
> >> Hi Chris,
> >> Aah! The volatile trick again... I spent some time reading about it,
> >> and it seems to be recommended to use especially when coding threads.
> >> This is a nice read;
> >> http://www.programmersheaven.com/articles/pathak/article1.htm
> >> I'm still unsure which variables would be the best candidates to
> >> become  volatile... but I know a couple of important ones that I
> >> could try  first.
> >> Thanks,
> >> -Ton-
> >>
> >> On 24 Feb, 2006, at 1:02, Chris Want wrote:
> >>> Ton Roosendaal wrote:
> >>>> Hi,
> >>>> I suspected scanline updating from crashing... it was reported to
> >>>> crash  less frequent then, but that's not the solution. Apparently
> >>>> I've put a  little bit too much efforts to limit code for update
> >>>> scanlines! So yes,  it skips the 2nd thread tile drawing. Will be
> >>>> brought back.
> >>>> We did tests a couple of days on irc with this .blend:
> >>>> http://www.blender.org/bf/untitled-1.blend
> >>>> Not sure if it still crashes, it seems to only happen every 10
> >>>> frames   or so. So just press ANIM on it.
> >>>> -Ton-
> >>>
> >>> I got the crashes too with that file (takes
> >>> about 70-90 frames here).
> >>>
> >>> Valgrind was giving me some inconsistent info,
> >>> so I start to play with the optimization levels.
> >>> I find that if I set the optimization for linux
> >>> to -O0 and then touch threads.c and all the stuff
> >>> in render/intern/source, then type "make", blender
> >>> no longer crashes. At -O1 it still crashes.
> >>>
> >>> Regards,
> >>> Chris
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at projects.blender.org
> >>> http://projects.blender.org/mailman/listinfo/bf-committers
> >>
> >> ----------------------------------------------------------------------
> >> -- --
> >> Ton Roosendaal  Blender Foundation ton at blender.org
> >> http://www.blender.org
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at projects.blender.org
> >> http://projects.blender.org/mailman/listinfo/bf-committers
> >
> > --
> > [ e d @ h a l l e y . c c ]
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
>
> ------------------------------------------------------------------------
> --
> Ton Roosendaal  Blender Foundation ton at blender.org
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers