pthreads ??
Are calls to suspend and resume ref counted? iow, if i do this in pseudo-code: thread->suspend(); thread->suspend(); thread->resume(); // thread is still suspended thread->resume(); // now thread runs is that the way it works for pthreads? elrod
RE: pthreads ??
>From what I can tell, nope. Shouldn't be more than 5 minutes work to add it, if that's how you want them to behave.. Isaac On 20-Sep-99 Mark B. Elrod wrote: > Are calls to suspend and resume ref counted? iow, if i do this in > pseudo-code: > > thread->suspend(); > thread->suspend(); > > thread->resume(); > // thread is still suspended > thread->resume(); > // now thread runs > > is that the way it works for pthreads? > > elrod > >
Re: pthreads ??
that is how i think it should work... and it is how i need it to work for my download stuff to work correctly. elrod Isaac Richards wrote: > >From what I can tell, nope. Shouldn't be more than 5 minutes work to add it, > if that's how you want them to behave.. > > Isaac > > On 20-Sep-99 Mark B. Elrod wrote: > > Are calls to suspend and resume ref counted? iow, if i do this in > > pseudo-code: > > > > thread->suspend(); > > thread->suspend(); > > > > thread->resume(); > > // thread is still suspended > > thread->resume(); > > // now thread runs > > > > is that the way it works for pthreads? > > > > elrod > > > >
Re: pthreads ??
> Are calls to suspend and resume ref counted? iow, if i do this in > pseudo-code: No. It just does a SIGSTOP and SIGCONT for suspend and resume. The first resume after N>=1 suspends will cause the task to restart. > is that the way it works for pthreads? Pthreads doesn't really have suspend/resume. Just SIGSTOP and SIGCONT. -- James Carlson, Software Architect <[EMAIL PROTECTED]> IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp
RE: pthreads ??
Jim Carlson sez:
>> Are calls to suspend and resume ref counted? iow, if i do this in
>> pseudo-code:
>
>No. It just does a SIGSTOP and SIGCONT for suspend and resume. The
>first resume after N>=1 suspends will cause the task to restart.
>
>> is that the way it works for pthreads?
>
>Pthreads doesn't really have suspend/resume. Just SIGSTOP and
>SIGCONT.
I agree with you, but it even gets worse than that. Let me elaborate.
The signal handling under LinuxThreads is different from the signal
handling under POSIX threads for one. And, as far as I can tell, the
signal handling is cooperative, and the current thread implementation
does not cooperative signal handling. The code for suspend and resume
is show here:
void
linuxThread::
Suspend()
{
m_suspendMutex->Acquire(WAIT_FOREVER);
if (!m_suspended) {
pthread_kill(m_threadHandle, SIGSTOP);
m_suspended = true;
}
m_suspendMutex->Release();
}
void
linuxThread::
Resume()
{
m_suspendMutex->Acquire(WAIT_FOREVER);
if (m_suspended) {
pthread_kill(m_threadHandle, SIGCONT);
m_suspended = false;
}
m_suspendMutex->Release();
}
So, I wrote this little test program, to see how well the
internals of Suspend and Resume work:
#include
#include
#include
#include
#include
void tprint(char *string)
{
time_t t;
time(&t);
printf("%s%s\n", ctime(&t), string);
}
void *worker_thread(void *pArg)
{
tprint("Worker thread start, sleeping 5 secs\n");
sleep(5);
tprint("Back from sleep, worker thread exiting...\n");
return NULL;
}
int main(int argc, char *pargv[])
{
pthread_t t;
t = pthread_create(&t, NULL, worker_thread, NULL);
tprint("Main thread starting\n");
sleep(1);
tprint("Suspending thread...\n");
pthread_kill(t, SIGSTOP);
sleep(10);
tprint("Exit...\n");
return 0;
}
The output of this program is:
Mon Sep 20 11:15:45 1999
Main thread starting
Mon Sep 20 11:15:45 1999
Worker thread start, sleeping 5 secs
Mon Sep 20 11:15:46 1999
Suspending thread...
Mon Sep 20 11:15:50 1999
Back from sleep, worker thread exiting...
Mon Sep 20 11:15:56 1999
Exit...
As you can see, the worker thread never gets interrupted or slowed
down. This is exactly what would happend with the current Thread.cpp
class for linux.
Conclusion: We should not use Suspend() and Resume(). As a matter of
fact it would be best for us to remove these calls from the classes
altogether.
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: gcc & Themes
On 17 Sep, Tom Spindler wrote: > gcc 2.95 doesn't like Theme.cpp: > > ui/theme/src/Theme.cpp: In method `enum Error Theme::BeginElement(string &, >map,__default_alloc_template >>,basic_string,__default_alloc_template >>,less,__default_alloc_template > >>,allocator,__default_alloc_template > > > > &)': > ui/theme/src/Theme.cpp:150: cannot allocate an object of type `GTKWindow' > ui/theme/src/Theme.cpp:150: since the following virtual functions are abstract: > ui/theme/include/Window.h:89: enum Error Window::Run(Pos &) > ui/theme/include/Window.h:90: enum Error Window::Close() > ui/theme/include/Window.h:102: enum Error Window::SetWindowPosition(Rect &) > ui/theme/include/Window.h:103: enum Error Window::GetWindowPosition(Rect &) > ui/theme/src/Theme.cpp:196: warning: unused variable `struct Rect oRect' > make[1]: *** [ui/theme/src/Theme.o] Error 1 > > (nice method line, eh?) Ok, that should compile nicely now. Sorry about that. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: gcc & Themes
On 20 Sep, Valters Vingolds wrote: > It wouldn't help you anyway - some places are Win32 specific (marked as > notes 'to be crossplatform') > so no fair running it under *nix. Well, its not implemeted under *nix right now anyway. It will be before too long, but not just yet. > besides, bitmaps that got downloaded in CVS (ui/themes/default) are > somewhat corrupted - won't load. > anyone with similar results? They're fixed now. > also, GetErrorString() usually returns NULL. > there should probably be another funtion, to get string for kError ret > values to display in case no recent oLastError is defined, because > GetErrorString usualy gets called when some ret value is !=NoErr. Yeah, that whole code section will get tossed in favor of something more robust as I get a few other issues hammered out. > nevertheless... Themes look to be real cool one (i hope we get them to be > flexible enough...). Depends on what you mean by flexible. Right now the theme support takes a very minimalistic approach -- there are text fields, buttons and horizontal sliders. I am playing around with adding a dial control and possible creating vertical sliders for completeness. The themes are based on an XML document that describes where the controls will go and what bitmaps to use to display them. Theoretically anyone with photoshop/gimp and html/xml experience should be able to make a FreeAmp theme. One core concept in the design of the themes was portability. I opted to not use any of the OS supplied controls and instead have the OS independent portion define all the controls. Each control has a finite state machine that defines transitions from one state to another based on mouse input and control value changes from the application. For instance, the button control consists of a transition table and a case statement for blitting the right bitmap in the right state. Very simple. But, I have no idea if that will be flexible enough. :-) --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
RE: pthreads ??
On 20-Sep-99 [EMAIL PROTECTED] wrote: > I agree with you, but it even gets worse than that. Let me elaborate. > The signal handling under LinuxThreads is different from the signal > handling under POSIX threads for one. And, as far as I can tell, the > signal handling is cooperative, and the current thread implementation > does not cooperative signal handling. The code for suspend and resume > is show here: Oh well, just another place where linux doesn't follow the standard.. Guess I shouldn't believe my ora pthreads book =) Isaac
1.5 on linux?
Hi! Should 1.5 work on linux? I can compile it, but can't run. I get this: flocsy@crux:~/work/freeamp/freeamp15$ ./freeamp /mp3/Ellenorzott/D/Dragana\ -\ Up\ And\ Down.mp3 /home/flocsy/work/freeamp/freeamp/plugins/freeampcmd.ui: undefined symbol: SetFirst__15PlayListManager /home/flocsy/work/freeamp/freeamp/plugins/mpg123.ui: undefined symbol: SetFirst__15PlayListManager /home/flocsy/work/freeamp/freeamp/plugins/lcd.ui: undefined symbol: SetFirst__15PlayListManager /home/flocsy/work/freeamp/freeamp/plugins/irman.ui: undefined symbol: SetFirst__15PlayListManager /home/flocsy/work/freeamp/freeamp/plugins/freeamp.ui: undefined symbol: SetFirst__15PlayListManager /home/flocsy/work/freeamp/freeamp/plugins/ncurses.ui: undefined symbol: SetFirst__15PlayListManager ./plugins/theme.ui: undefined symbol: __13MessageDialog ./plugins/ncurses.ui: undefined symbol: color_set Segmentation fault (core dumped) Is it a bug/error at my system/or am I just in the middle of a cvs update and should try later? FlöcsyŽ URL: http://flocsy.spedia.net MAIL:[EMAIL PROTECTED] SMS: [EMAIL PROTECTED] ICQ:27733935 Ha meg szeretnéd tudni hogyan kereshetsz böngészés közben egy kis zsebpénzt: http://www.spedia.net/cgi-bin/dir/tz.cgi?run=show_svc&fl=8&vid=119891
Re: 1.5 on linux?
> I can compile it, but can't run. I get this: > flocsy@crux:~/work/freeamp/freeamp15$ ./freeamp > /mp3/Ellenorzott/D/Dragana\ -\ Up\ And\ Down.mp3 > /home/flocsy/work/freeamp/freeamp/plugins/freeampcmd.ui: undefined symbol: > SetFirst__15PlayListManager make clean; make. If your system can handle `make depend`, you should do so after CVS updates; changes in the header files can cause things to not link properly.
extreme solaris wackiness
Well, I think I'm getting closer to finding what's causing the Solaris strangeness; for one, it appears that sometimes the LWP or Reader gets stuck, and so WasteTime() gets called an awful lot. A side effect seems to be the creation of several hundred threads. :) (gdb) info threads 640 Thread 511 0xff04b7dc in _restorefsr () from /usr/lib/libthread.so.1 639 Thread 510 0xff04b7dc in _restorefsr () from /usr/lib/libthread.so.1 and so on.
HTTP/1.1 download lib
in freeamp we are going to support http/1.1 downloading. i would rather not reimplement this from scratch. anyone have a nice lib they can point me too? elrod
LocalFileInput race condition, somewhere.
When I click too quickly on the 'next song' button, it appears that m_pSleepSem gets set somewhere, but doesn't get released. I suspect that there's something funny going on with the ->Signal() call, but I can't say for sure yet.
even more solaris ranting
I've gotten the strangest hang yet. It's hanging inside of Player::EventServiceThreadfunc, at pP->m_eventSem->Wait(). The kicker is that there are no other threads alive that even reference that semaphore! In fact, the only place that this particular variable is used is player.cpp. a (long) backtrace follows. (gdb) set height 0 (gdb) thr ap al bt Thread 14 (Thread 4 (LWP 6)): #0 0xff115c90 in _poll () from /usr/lib/libc.so.1 #1 0xff0ce674 in select () from /usr/lib/libc.so.1 #2 0xff04b1d4 in select () from /usr/lib/libthread.so.1 #3 0xff2f3514 in _XRead () from /usr/openwin/lib/libX11.so.4 #4 0xff2f7e58 in _XReadEvents () from /usr/openwin/lib/libX11.so.4 #5 0xff2f445c in XNextEvent () from /usr/openwin/lib/libX11.so.4 #6 0xfe5325ec in FreeAmpUI::X11EventService (this=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:545 #7 0xfe532528 in FreeAmpUI::x11ServiceFunction (p=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:509 #8 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #9 0x417a8 in solarisThread::internalThreadFunction (arg=0x87768) at base/unix/solaris/src/solaristhread.cpp:64 Thread 13 (LWP13): #0 0xff11501c in door_restart () from /usr/lib/libc.so.1 Thread 12 (LWP12): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 11 (LWP11): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 10 (LWP10): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 9 (LWP9): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 8 (LWP8): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 7 (LWP7): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 6 (LWP6): #0 0xff115c90 in _poll () from /usr/lib/libc.so.1 #1 0xff0ce674 in select () from /usr/lib/libc.so.1 #2 0xff04b1d4 in select () from /usr/lib/libthread.so.1 #3 0xff2f3514 in _XRead () from /usr/openwin/lib/libX11.so.4 #4 0xff2f7e58 in _XReadEvents () from /usr/openwin/lib/libX11.so.4 #5 0xff2f445c in XNextEvent () from /usr/openwin/lib/libX11.so.4 #6 0xfe5325ec in FreeAmpUI::X11EventService (this=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:545 #7 0xfe532528 in FreeAmpUI::x11ServiceFunction (p=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:509 #8 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #9 0x417a8 in solarisThread::internalThreadFunction (arg=0x87768) at base/unix/solaris/src/solaristhread.cpp:64 Thread 5 (LWP5): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 4 (LWP4): #0 0xff117544 in _sigsuspend () from /usr/lib/libc.so.1 #1 0xff0499f4 in sigsuspend () from /usr/lib/libthread.so.1 #2 0xff0d6c44 in _usleep () from /usr/lib/libc.so.1 #3 0xff04b274 in usleep () from /usr/lib/libthread.so.1 #4 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #5 0x417a8 in solarisThread::internalThreadFunction (arg=0x87790) at base/unix/solaris/src/solaristhread.cpp:64 Thread 3 (LWP3): #0 0xff117a74 in _lwp_sema_wait () from /usr/lib/libc.so.1 #1 0xff03b04c in _park () from /usr/lib/libthread.so.1 #2 0xff03ad40 in _swtch () from /usr/lib/libthread.so.1 #3 0xff039a00 in cond_wait () from /usr/lib/libthread.so.1 #4 0xff039924 in pthread_cond_wait () from /usr/lib/libthread.so.1 #5 0x41b5c in Semaphore::Wait (this=0x886e8) at base/unix/solaris/src/semaphore.cpp:50 #6 0x313c8 in Player::EventServiceThreadFunc (pPlayer=0x885a0) at base/src/player.cpp:585 #7 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #8 0x417a8 in solarisThread::internalThreadFunction (arg=0x877b8) at base/unix/solaris/src/solaristhread.cpp:64 Thread 2 (LWP2): #0 0xff117444 in _signotifywait () from /usr/lib/libc.so.1 #1 0xff03f598 in _dynamiclwps () from /usr/lib/libthread.so.1 Thread 1 (LWP1
Re: 1.5 on linux?
On Mon, 20 Sep 1999, Tom Spindler wrote: > If your system can handle `make depend`, you should do so after CVS Hmm. The problem is that I do this every time: cd freeamp/cvs ; cvs -d update ; cd .. cp -R cvs/freeamp freeamp ; cd freeamp ./configure ; make Flocsy Gabor Fleischer MAILTO: [EMAIL PROTECTED] URL: http://www.mtesz.hu/~flocsy SMS: [EMAIL PROTECTED] ICQ UIN: 27733935
