Sorry I meant to include the error in the last email:
/bin/sh ../libtool --tag=CC --mode=link gcc -I /opt/local/include -L/opt/local/lib -o libreplace.la dummy.lo -lpthread -lcrypto -lz -lltdl -ldl -ljpeg
ar cru .libs/libreplace.a .libs/dummy.o~ranlib .libs/libreplace.a
ar: .libs/dummy.o~ranlib: No such file or directory
$ ls -l replace/.libs/
-rw-r--r-- 1 gorn gorn 384 May 2 17:00 dummy.o
-rw-r--r-- 1 gorn gorn 76 May 2 17:00 libreplace.a
On Apr 30, 2007, at 6:53 PM, Kevin Barry wrote:
> Most of the issues I was having before are no longer. I wonder if I
> checked out right when someone was checking in, or my checkout
> silently failed part way through or something. But I'm still having
> libtool issues. If I use the libtool script from player-2.0.3 it
> builds fine.
The libtool script that is generated by autoreconf doesn't work?
What errors do you see?
> On Mac when Player doesn't have any clients connected, the CPU
> usage jumps to 100%. Once a client connects, it drops
> significantly. This doesn't seem to effect Linux however. (I didn't
> investigate the TCP/UDP libraries to fully understand why. It could
> be that my patch is really just covering up a bigger problem)
I've seen the same thing. This is because OS X has a smaller
scheduling timeslice than Linux (a result of the microkernel
architecture, I suppose). There is in fact a sleep in Player's main
loop, but only for 1us. On Linux, this sleep is impossible to
achieve, but OS X can just about do it, resulting in a busy loop. We
fixed this by increasing the main loop sleep to 1ms, which seems to
work well on both platforms, and will still allow for 1KHz operation.
> To fix it I've added a check to see if we have no clients, if
> that's the case, it sleeps for .1 seconds.
> The only possible downside I can think of (But I could be
> overlooking something! Someone double check me) is that there is up
> to a .1 second additional delay for the first client to connect.
> This seems quite acceptable.
There can be drivers running with no clients connected, and if any of
them are non-threaded (i.e., updated from the main server thread),
such as Stage, then this extra sleep will slow them down. This is
not a good thing, not because of the length of the sleep, but because
of the significant change in timing for such drivers depending on
whether clients are connected.
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Playerstage-developers mailing list