[Bf-committers] Pretty clueless Linux threads crashing...
antont at kyperjokki.fi
Fri Feb 24 14:33:44 CET 2006
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
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
but yah, am also hoping that using phtreads directly will solve the
> 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
> Bf-committers mailing list
> Bf-committers at projects.blender.org
More information about the Bf-committers