On Wed, 18 Apr 2001, Jeremy C. Reed wrote:

> Using 1.5.1_BETA for i386. I built devel/smpeg (smpeg-0.4.1). The test
> programs plaympeg, gtv, and glmovie don't work for me.

I have been researching this further. I have a few questions below.

1) A Loki developer has logged onto my machine to work on SDL.

2) Steven M. Schultz created a "sem" port that worked so he could get the
SDL kit and plaympeg working (under BSD/OS):

       Sys V IPC semaphores are unsafe to use in a threaded environment
       because there is no mutex protection against simultaneous
       access of the semaphores.   If the SDL can not find 'sem_init',
       'sem_post', etc (POSIX semaphores) which are thread aware/safe
       then the non-safe SysV sempaphores will be used instead.    What I
       did was take the FreeBSD 'uthread_sem.c' file and "port" it to
       BSD/OS - at which point the SDL and smpeg-0.4.2 worked flawlessly.

He says his ftp://ftp.to.gd-es.com/pub/sem.tar.bz2 package is simple
enough that it should port to any BSD system that has threads but
lacks POSIX semaphores.

Is there any POSIX semaphores work being done for NetBSD? (I searched via
the mailing list archive and found nothing.)

So I built and installed his libsem (with a couple modifications); and
built SDL against it (--enable-pthread-sem and added "-lsem" to Makefiles
and modified sdl-config to also output "-lsem") and built smpeg again.

3) plaympeg still hung. So I ktraced it this time. ktrace.out grew to 9MB
in just a few moments.

Probably over 8MB was a loop:

 17935 plaympeg CALL  lseek(0x7,0,0xffffc000,0,0x2)
 17935 plaympeg RET   lseek 594276/0x91164
 17935 plaympeg CALL  read(0x7,0x8084000,0x4000)
 17935 plaympeg RET   read 0
 17935 plaympeg CALL  lseek(0x7,0,0xffff8000,0,0x2)
 17935 plaympeg RET   lseek 577892/0x8d164
 17935 plaympeg CALL  read(0x7,0x8084000,0x4000)
 17935 plaympeg RET   read 0

counting down to (until I killed it):

 17935 plaympeg CALL  lseek(0x7,0,0xce0d8000,0,0x2)
 17935 plaympeg RET   lseek -837365404/0xce16d164
 17935 plaympeg CALL  read(0x7,0x8084000,0x4000)
 17935 plaympeg RET   read 0
 17935 plaympeg CALL  lseek(0x7,0,0xce0d4000,0,0x2)
 17935 plaympeg RET   lseek -837381788/0xce169164
 17935 plaympeg CALL  read(0x7,0x8084000,0x4000)
 17935 plaympeg RET   read 0
 17935 plaympeg PSIG  SIGKILL SIG_DFL

This all happens after it reads the mpeg file and does a bunch of:
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  __sigprocmask14(0x3,0x805b584,0)
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  __sigprocmask14(0,0,0x805b584)
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  __sigprocmask14(0x3,0x805b284,0)
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  gettimeofday(0x806ff04,0)
 17935 plaympeg RET   gettimeofday 0
 17935 plaympeg CALL  __sigpending14(0x48132510)
 17935 plaympeg RET   __sigpending14 0
 17935 plaympeg CALL  read(0x5,0x806fa84,0x80)
 17935 plaympeg RET   read -1 errno 35 Resource temporarily unavailable
 17935 plaympeg CALL  __sigprocmask14(0x3,0x48132520,0x806fe4c)
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  select(0x6,0x806fe9c,0x806fe7c,0x806fe5c,0x806fa6c)
 17935 plaympeg RET   select 0
 17935 plaympeg CALL  __sigprocmask14(0x3,0x806fe4c,0)
 17935 plaympeg RET   __sigprocmask14 0
 17935 plaympeg CALL  gettimeofday(0x805b344,0)
 17935 plaympeg RET   gettimeofday 0
 17935 plaympeg CALL  __sigprocmask14(0,0,0x805b284)
 17935 plaympeg RET   __sigprocmask14 0

Any ideas?

Since SDL and smpeg are packaged -- do they work for anyone?

Thanks,

   Jeremy C. Reed
   http://www.reedmedia.net/