Carsten wrote:
>>> it's perfectly threadsafe. it has nothing to do with threads. it has to do
>>> with there being no emms called before doing fp ops.
>>>
>> I don't think so. And emms isn't needed there without threads,
>> not when all funcs clean up after themselves. Disable pipes and you
>> don't need that.
>>
>
> it has nothing to do with threads. i repeat. it'd threadsafe. it has to do
> with
> processor fp/mmx mode. each core will retain its OWN mode. threads themseleves
> have nothing to do with it.
>
>
How can they have nothing to do with it when the problem simply
doesn't show up without your pipes enabled? Are saying that threads
simply "bring it out..."? Bring what out, the magic juju?
Sure what's happening is fp/mmx conflicts but the question is
why is it happening - why doesn't it happen without pipes but does with
them.
If all evas internal rendering functions are releasing mmx
registers correctly, then it shouldn't happen (at least) in a non-
threaded situation.. and if you disable pipes I have yet to hear
of an example where anyone sees it (with recent stuff). But with
the pipes, the execution path seems less well-determined.. and
suddenly, the problem shows up all the time. Same code, same examples
- pipes disabled no problem, pipes enabled big problems.
What's the reason there's a difference?
____________________________________________________________
Click here to find old friends, lovers or family.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oCe34isfl18SPSp9cXG9VOvh0IPExKyKzrJPDYmCmhtnRe4/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
