This program behaves very unpredictably… Sometimes can’t get input
from keyboard, sometimes quits immediatly, sometimes crashes with
SIGFAULT or hangs, sometimes doesn’t open window, but never runs
correctly…
SDL_Quit ();
}
I’m not quite sure, but this program looks like you have some wrong
thoughts. Try to make this main do the events-processing-loop … and not
quit after initializing the threads. I guess, SDL is already finished when
your event-thread tries to use it … but as I said, I’m not sure and I
don’t have any thread-experience.
St0fF.
This program behaves very unpredictably… Sometimes can’t get input
from keyboard, sometimes quits immediatly, sometimes crashes with
SIGFAULT or hangs, sometimes doesn’t open window, but never runs
correctly…
how about adding in SDL_INIT_EVENTTHREAD to the SDL_Init flags…perhaps.
threads are somewhat overrated in this particular case…you probably should not use them, stick to the plain event&display loop…–
-==-
Jon Atkins http://jcatki.2y.net/
As for OpenGL, you will have to make the context the current GLX/WGL/AGL/…
rendering context of the calling thread, if you want to draw from another
thread than the thread which created the OpenGL context.
If you really cannot avoid multiple threads (in almost all cases you can
avoid threads),
you could write a hack to use native GLX/WGL/AGL/… context switch functions
with internal SDL data which can be retrieved via
SDL_GetWMInfo(SDL_SysWMinfo *info); and call them at the beginning of your
thread function.On Monday 11 March 2002 22:39, Jan Klesnil wrote:
Can SDL run with one thread for drawing in OpenGL, one thread for
event-handling, one thread… ? I it can, what am I doing wrong?
Maybe a bit OT, but threading is definitely something to avoid,
unless you are 120% sure what you are doing in the threads.
Threads are very hard to debug, both MSVC and GDB fail flat
at this. I recently just convert a program with 4 threads
into 1, and found it much more stable and almost all bugs can
now be instantly fixed, which used to take weeks or even months.
Of course this is by no means saying thread is bad, but avoiding
threading is actually to avoid human errors, especially when
there are more than one person working on the same codebase.
Regards,
.paul.On Tue, Mar 12, 2002 at 02:41:16PM +0100, Johannes Schmidt wrote:
If you really cannot avoid multiple threads (in almost all cases you can
avoid threads),
Speaking of which, do you happen to know of any gdb for x86 with any
kind of thread support? (That is, one that doesn’t just quit, leaving
crap threads all over the place as soon as another thread is started…)
I looked and found some “evidence” that there should be a patch, but I’ve
failed to find the actual code. :-/
(It’s kind of hard doing low latency audio + GUI in only one thread, you
know…
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 12 March 2002 15:05, paul at theV.net wrote:
On Tue, Mar 12, 2002 at 02:41:16PM +0100, Johannes Schmidt wrote:
If you really cannot avoid multiple threads (in almost all cases you
can avoid threads),
Maybe a bit OT, but threading is definitely something to avoid,
unless you are 120% sure what you are doing in the threads.
Threads are very hard to debug, both MSVC and GDB fail flat
at this.
Kind of sad, that is the most frustrating thing I have with gdb too…
If you keep all threads running, you may switch between threads and
inspect each, and I guess that is it :PPP
Regards,
.paul.On Tue, Mar 12, 2002 at 06:15:30PM +0100, David Olofson wrote:
Speaking of which, do you happen to know of any gdb for x86 with any
kind of thread support? (That is, one that doesn’t just quit, leaving
crap threads all over the place as soon as another thread is started…)
I looked and found some “evidence” that there should be a patch, but I’ve
failed to find the actual code. :-/
Problem is that on my systems, gdb just dies as soon as the debugged
process gets more than one thread. No way to do anything with a
multithreaded application… :-/
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 13 March 2002 03:19, paul at theV.net wrote:
On Tue, Mar 12, 2002 at 06:15:30PM +0100, David Olofson wrote:
Speaking of which, do you happen to know of any gdb for x86 with any kind of thread support? (That is, one that doesn’t just quit,
leaving crap threads all over the place as soon as another thread is
started…) I looked and found some “evidence” that there should be a
patch, but I’ve failed to find the actual code. :-/
Kind of sad, that is the most frustrating thing I have with gdb too…
If you keep all threads running, you may switch between threads and
inspect each, and I guess that is it :PPP
| Problem is that on my systems, gdb just dies as soon as the debugged
| process gets more than one thread. No way to do anything with a
| multithreaded application… :-/
It’s an obvious suggestion, but try upgrading gdb I’ve got version
5.0, and if I debug a threaded program, I get this kind of thing:
Yeah, that’s what I want. I’ve tried 5.1, 5.1.1 and yesterday’s snapshot,
but they all just terminate.
It doesn’t seem to be a problem with gdb itself, but rather some library
on my systems. Of course, libpthreads is the first one I’d suspect…
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 13 March 2002 21:47, James wrote:
On Wed, Mar 13, 2002 at 08:19:14PM +0100, David Olofson wrote:
| Problem is that on my systems, gdb just dies as soon as the
| debugged process gets more than one thread. No way to do anything
| with a multithreaded application… :-/
It’s an obvious suggestion, but try upgrading gdb I’ve got version
5.0, and if I debug a threaded program, I get this kind of thing:
| Yeah, that’s what I want. I’ve tried 5.1, 5.1.1 and yesterday’s snapshot,
| but they all just terminate.
|
| It doesn’t seem to be a problem with gdb itself, but rather some library
| on my systems. Of course, libpthreads is the first one I’d suspect…
So remember the first rule of using a debugger:
“If the debugger crashes when in use, stop debugging your program, and
debug the debugger”
(should you attempt this, you might want to look up “Psychiatrist” in
your phonebook first :-)On Wed, Mar 13, 2002 at 11:07:24PM +0100, David Olofson wrote:
i wouldn’t run openGL video functions in a separate thread, it tends to
give extremely strange results. i tried it once, and i couldn’t get
transparency (alpha blending) to work when drawing in a thread. the same
code worked fine when the drawing routine was in the main thread…
eikOn Tue, 12 Mar 2002, St0fF 64 wrote:
At 21:39 11.03.2002 +0000, you wrote:
Can SDL run with one thread for drawing in OpenGL, one thread for
event-handling, one thread… ? I it can, what am I doing wrong?
SDL_Quit ();
}
I’m not quite sure, but this program looks like you have some wrong
thoughts. Try to make this main do the events-processing-loop … and not
quit after initializing the threads. I guess, SDL is already finished when
your event-thread tries to use it … but as I said, I’m not sure and I
don’t have any thread-experience.
St0fF.
| Yeah, that’s what I want. I’ve tried 5.1, 5.1.1 and yesterday’s
| snapshot, but they all just terminate.
|
| It doesn’t seem to be a problem with gdb itself, but rather some
| library on my systems. Of course, libpthreads is the first one I’d
| suspect…
So remember the first rule of using a debugger:
“If the debugger crashes when in use, stop debugging your program, and
debug the debugger”
Actually, I tried, but the fact that it terminates because of
"unexpected" output from the new thread (same thing that happens if you
start an application with &, and it decides to use stdout) doesn’t
tell me too much.
Why does that happen, and what do I do about it? heh
(should you attempt this, you might want to look up “Psychiatrist” in
your phonebook first
No need… yet!
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 13 March 2002 23:35, James wrote:
On Wed, Mar 13, 2002 at 11:07:24PM +0100, David Olofson wrote:
I’ve got version