2
votes

I'm starting a project using SDL2 to display the result of the Dining philosophers problem. I was creating 7 threads for my "philosophers" using pthread_create but I've noticed always 5 more threads than necessary using ps -M.

Example (with 7 of my voluntarily created threads [confirmed with some text output]):

achedeuzot 56774 s000    0.9 U    46T   0:00.04   0:00.06 ./philo
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    48T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00
           56774         0.0 S    46T   0:00.00   0:00.00

When I disable the code that generates threads but keep displaying a window, there are still 5 threads remaining:

achedeuzot 57751 s000    0.9 U    46T   0:00.04   0:00.06 ./philo
           57751         0.0 S    46T   0:00.00   0:00.00
           57751         0.0 S    48T   0:00.00   0:00.00
           57751         0.0 S     0T   0:00.00   0:00.00
           57751         0.0 S    46T   0:00.00   0:00.00
           57751         0.0 S    46T   0:00.00   0:00.00

So it seems that SDL2 is creating 5 threads on it's own. I'm using SDL_RENDERER_ACCELERATED for SDL_CreateRenderer().

I have searched for other people mentioning this but couldn't find anything about it (or my keywords were not OK).

Where are these 5 extra threads coming from ? Is it something specific to my computer ? Is it from the GPU acceleration ? Is it from the ps command ? Is it SDL2 or some sub-routine of SDL2 ?

Thank you for helping me see more clearly what is happening here !

Additional info: I'm not using SDL_CreateThread(). I'm on a Mac, OS 10.9.3.

1
So threads are created, regardless of your code? - this
It seems so. I would like to know if others have noticed the same thing by using SDL2 or if it's something "strange" on my computer. - achedeuzot
My old sdl 1.2 program creates an additional thread on its own, ( no opengl ) - this
Is it SDL 1 or 2? Something with the new version? - achedeuzot
Not by just including it but some actual calls. Use a debugger to find out what the threads are doing or look at SDL's sources if you need. - Ulrich Eckhardt

1 Answers

2
votes

Taking a quick look at the latest SDL2 sources, a quick grep for 'SDL_CreateThread' reveals

src/video/cocoa/SDL_cocoamousetap.m
src/video/winrt/SDL_winrtevents.cpp
src/video/psp/SDL_pspevents.c
src/timer/SDL_timer.c
src/main/haiku/SDL_BeApp.cc
src/haptic/windows/SDL_syshaptic.c
src/dynapi/SDL_dynapi.c
src/dynapi/SDL_dynapi_overrides.h
src/dynapi/SDL_dynapi_procs.h
src/thread/SDL_thread.c
src/joystick/winrt/SDL_xinputjoystick.c
src/joystick/windows/SDL_dxjoystick.c
src/joystick/psp/SDL_sysjoystick.c
src/audio/SDL_audio.c

Of those, you're probably interested in cocoa specific and general invocations. Narrowing in on the cocoa case we see:

void
Cocoa_InitMouseEventTap(SDL_MouseData* driverdata)
{
    SDL_MouseEventTapData *tapdata;
    driverdata->tapdata = SDL_calloc(1, sizeof(SDL_MouseEventTapData));
    tapdata = (SDL_MouseEventTapData*)driverdata->tapdata;

    tapdata->runloopStartedSemaphore = SDL_CreateSemaphore(0);
    if (tapdata->runloopStartedSemaphore) {
        tapdata->thread = SDL_CreateThread(&Cocoa_MouseTapThread, "Event Tap Loop", tapdata);
        if (!tapdata->thread) {
            SDL_DestroySemaphore(tapdata->runloopStartedSemaphore);
        }
    }

    if (!tapdata->thread) {
        SDL_free(driverdata->tapdata);
        driverdata->tapdata = NULL;
    }
}

So at least one thread for mouse events there. Perhaps another thread or two for timers and audio as well.

If you really want to know what those threads are doing, by far the easiest thing is going to be attaching with 'gdb -p' and running 'thread apply all backtrace'.