Bob Pendleton <bob pendleton.com> writes:
Platform is Linux but I’d like to be portable to at least other Unix.
I’d like to know if there is a way to cause SDL_WaitEvent() to wake up for
system events including itimer/alarm events, as well as selected file
descriptors being ready … WITHOUT having to run another thread.
Depends on the OS and how much work you want to do. If the APIs you
want to use can be made to call a call back function then the call
back can add an event to the SDL event queue and that will cause
SDL_Waitevent() to wake up. If the answer is no, then the answer is no
for SDL too.
Hopefully, I will need to do very little with threads. I certainly won’t be
putting different contexts of work inside threads where I can avoid it
(and I’ve managed to avoid it for years).
What I’m looking at doing is simply a few network connections in a program
using SDL to display a graphical screen. Pipes to forked processes may also
be involved. What I need to do is have an event loop that wakes up on any
file descriptor becoming ready, or any signal arriving, or anything that
would normally wake up SDL_WaitEvent. Since there is no interface that lets
me tell SDL to also include those events, and SDL does not expose what file
descriptor(s) it might be waiting on (for me to do the select() or poll()
system call myself … which can be done with Xlib), then the only thing I can
come up with is the following:
I will create a 2nd thread with SDL_CreateThread(). This 2nd thread will wait
in a call to SDL_SemWait(). When it wakes up, it will pick up a descriptor
list and call select() or poll(). When it wakes up, it will call
SDL_PushEvent() to push a user event into the queue. After that it goes
back around to the call to SDL_SemWait().
When the main thread has no work to do, it will construct a descriptor list
of what descriptors it could work with and save that for the 2nd thread to
get. Then it will call SDL_SemPost() to wake up the 2nd thread, and call
SDL_WaitEvent(). When it wakes up, it deals with the event(s) in the queue.
For the user event, it will look at what descriptor(s) is/are now ready, and
do what it needs to do with them. When it is done dealing with the event and
any work inspired by the event, it rolls back around to construct a new
descriptor list and so on.
I have seen other libraries in the past that provided some kind of event
management. A few had the ability to support waiting also on descriptors
and signals specified by the calling program. Those made life simpler.
Given that SDL is targeted to be portable over many platforms, I can see why
that’s not an integral part of the design. Still, there could have been some
system specific calls not crucial to the API (e.g. only non-portable programs
would ever call this) to do this. There might have been some other means.
Better to ask and hear everyone say “no, does not exist”, than to do some
more complex solution that didn’t have to be done.
I definitely want to avoid POSIX threads.
I’m not going to clutter up this discussion thread. I don’t use pthreads for
many reasons. If I need to use a minimal amount of threading to use SDL, I
will. But I don’t see pthreads as being minimal. The threading calls SDL
provides (even if it uses pthreads under the hood) is at least inimal,
I’m also want to minimize the discussions here because the web interface doesn’t
work very well (it has an 80 column limit, but has the text box set up to
obscure where those limits are exceeded).
I don’t know enough of what SDL
threads are to know if this may or may not be an issue for me. I’m concerned
particularly about limitations I read about concerning SDL threads:
- Don’t use any library functions in separate threads
- Don’t perform any memory management in separate threads
Where did you get this stuff? This is true for all thread packages if
the, and only if, the run time libraries are not thread safe. In the
bad old days, and I supposed on some crippled OSes, the run time
libraries are still not thread safe. On all major systems the
libraries are either thread safe or there is a compiler/linker flag
that you can set to say you need thread safe compilation and
Libraries can be thread-safe in one threading library, and not in another.
For example, if they need to lock around a critical resource (like a queue
that has to be shared over all thread usage), they might detect threads in
operation and use the appropriate locking call for that threading library.
So a library might be fine in pthreads, and not so with SDL’s threads.
That kind of detail is not described. So what SDL’s documentation is saying
could mean many things.
If I were to have a 2nd thread running to create fake events to get the main
event loop to act on things like a timed event, or a network connection
getting incoming data (to be displayed in the SDL window), that would means
two threads doing library calls.
Yep, and as the author of the fastevents and net2 libraries for SDL I
can tell you that that has worked just fine since before 2002 when I
You really have to check your sources of information much more
carefully. You are talking about problems that haven’t been problems
since at least the '90s.
My source of information is SDL documentation, specifically thread.html file
in the downloadable documentation tarball. Since it was discussing SDL
threads, I assume it to be the authority on the matter. Quoting:
- Don’t use any library functions in separate threads
What else should I know about SDL threads?> On Sat, Sep 12, 2009 at 2:35 AM, Phil Howard <phil-sdl ipal.net> wrote: