summaryrefslogtreecommitdiff
path: root/src/thread
AgeCommit message (Collapse)Author
2019-03-05Remove: MorphOS / AmigaOS supportPatric Stout
In 10 years there is no commit to change how MorphOS works, and we have no active maintainer for it. It is unlikely it works in its current state (but not impossible). With the arrival of SDL2 (and removal of SDL), MorphOS is no longer support. There is an SDL2 port for MorphOS, but it is not maintained by upstream SDL2, and nobody can currently test it out. If anyone wants to re-add MorphOS, please do (revert this patch, fix the problems, and create a Pull Request). If you need any help doing so, let us know! It is not that we don't like MorphOS, it is that we don't have anyone fixing the problems :(
2018-04-11Remove: NO_DEBUG_MESSAGES was only read and setting it broke compilation (#6703)Patric Stout
Given any speed issue cannot be attributed to checking for _debug_NNN_level, removing this is a safe action This fixes #6652.
2018-04-10Codechange: [OSX] Try to set the thread name for debugger display.Michael Lutz
2016-10-30(svn r27673) -Add: [Win32] Thread names for windows debuggers.michi_cc
2016-10-30(svn r27670) -Add: [FS#6471] Assign descriptive names to (GNU pthread) ↵frosch
threads. (JGR)
2014-12-24(svn r27092) -Fix/Add [FS#6186]: Compilation on OS/2 (smedles)frosch
2014-04-23(svn r26482) -Codechange: add an include that allows us to undefine/redefine ↵rubidium
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
2014-02-18(svn r26353) -Fix (r26349) [FS#5917]: Win32 and OS/2 ↵frosch
ThreadMutex::WaitForSignal always asserted.
2014-02-16(svn r26350) -Fix (r26349): Silly bugs are silly.frosch
2014-02-16(svn r26349) -Add: Optional recursive locking of mutexes.frosch
2014-02-16(svn r26342) -Add: A mutex locker class.fonsinchen
2013-01-08(svn r24900) -Fix [FS#5389]: Comments with typos (most fixes supplied by ↵planetmaker
Eagle_rainbow)
2011-12-10(svn r23481) -Add: Function to get the CPU core count.michi_cc
2011-05-01(svn r22405) -Document: some more "random-ish" tidbitsrubidium
2010-10-01(svn r20860) -Cleanup: remove some unused functions and variablessmatz
2010-09-17(svn r20823) -Codechange: enable/add some error/sanity checking in the ↵rubidium
pthread code
2009-12-29(svn r18656) -Feature: Add event semaphore support for OS/2orudge
2009-10-15(svn r17776) -Codechange: [SDL] make "update the video card"-process ↵rubidium
asynchronious. Profiling with gprof etc. hasn't shown us that DrawSurfaceToScreen takes a significant amount of CPU; only using TIC/TOC it became apparant that it was a heavy CPU-cycle user or that it was waiting for something. The benefit of making this function asynchronious ranges from 2%-25% (real time) during fast forward on dual core/hyperthreading-enabled CPUs; 8bpp improvements are, in my test cases, significantly smaller than 32bpp improvements. On single core non-hyperthreading-enabled CPUs the extra locking/scheduling costs up to 1% extra realtime in fast forward. You can use -v sdl:no_threads to disable threading and undo this loss. During normal non-fast-forwarded games the benefit/costs are negligable except when the gameloop takes more than about 90% of the time of a tick. Note that allegro's performance does not improve with this system, likely due to their way of getting data to the video card. It is not implemented for the OS X/Windows video backends, unless (ofcourse) SDL is used there. Funny is that the performance of the 32bpp(-anim) blitter is, at least in some test cases, significantly faster (more than 10%) than the 8bpp(-optimized) blitter when looking at real time in fast forward on a dual core CPU; it was slower. The idea comes from a paper/report by Idar Borlaug and Knut Imar Hagen.
2009-09-01(svn r17339) -Codechange: move thread related files to their own directory ↵rubidium
(like done for video, music, sound, etc)