shm interface problems

[mattes]

Olivier,

thanks for your response, I really appreciate it.

I am not quite sure about what the mutex is supposed to lock?
Are you saying I need to protect threadA monitoring the client
connection:

   mutex_lock();
   rc = sp_writer_recv( spipe, client );
   mutex_unlock();

Mat

On Wed, 16 Jan 2013 12:16:43 -0500 Olivier Crête <olivier.crete at collabora.com>
wrote

> Hi,
> 
> All calls to shmpipe.c must be protected by a mutex. Also you can NOT
> re-use the buffer before it has been freed by the receiving side. The
> shmpipe API is a bit deficient as it's missing a reliable way to
> indicate that (fixing it is on my to do list). I suggest allocating a
> new buffer every time you want to send.. and discard it after having
> called sp_writer_send_buf().
> 
> So in ThreadB doing:
> mutex_lock();
> sblock = sp_writer_alloc_block( spipe, shmbufLen );
> shmBuf = sp_writer_block_get_buf( sblock );
> mutex_unlock(); // optional if you want to do more than just memcpy() here..
> memcpy ( shmBuf, frame, shmbufLen );
> mutex_lock(); // optional 
> int nc = sp_writer_send_buf( spipe, shmBuf, shmbufLen );
> shm_alloc_space_block_dec(sblock);
> mutex_unlock();
> 
> Olivier
> 
> On Wed, 2013-01-16 at 08:51 -0800, mattes wrote:
> > I am using shmpipe.c with shmalloc.c, pretty much emulating
> > what shmsink does.
> > 
> > I looked at the shmsink source. But i can't identify any kind of lock you
> > mentioned. Any pointers are appreciated.
> > 
> > Here is what I am doing:
> > 
> > threadA:
> > - create the listener interface. 
> >   spipe = sp_writer_create( udSocketName, shmbufLen, FILE_MODE  );
> > - wait for incoming connections
> >   readsocks = select(highsock+1, &socks, (fd_set *) 0, (fd_set *) 0,
> >   &timeout); > - start gstreamer encoding pipeline
> > - receive and prep incoming connection
> >          sblock = sp_writer_alloc_block( spipe, shmbufLen );
> >          shmBuf = sp_writer_block_get_buf( sblock );
> >   to assign a single large shared memory buffer 
> > - then use 
> >         rc = sp_writer_recv( spipe, client );
> >   to monitor the connection
> > 
> > ThreadB:
> > - frame gets fed into shmsink via
> >    memcpy ( shmBuf, frame, shmbufLen );
> >    int nc = sp_writer_send_buf( spipe, shmBuf, shmbufLen );
> > 
> > As of now the 'sink' code supports only one connection at a time.
> > It is using one large shared memory buffer to have a more efficient
> > memory copy.
> > 
> > Mat
> > 
> > On Wed, 16 Jan 2013 09:23:15 -0500 Olivier Crête
> > <olivier.crete at collabora.com> wrote
> > 
> > > On Wed, 2013-01-16 at 00:34 -0800, mattes wrote:
> > > > Just wondering if anybody does run shm sink/src successfully on
> > > > Atom based platforms?
> > > 
> > > We have, are you using shmpipe.c on your sink side? or the entier
> > > GStreamer element? If you're just using shmpipe.c, you must make sure
> > > your locking is correct. Otherwise, it sounds like an application
> > > problem, maybe run it in valgrind ?
> > > 
> > > -- 
> > > Olivier Crête
> > > olivier.crete at collabora.com
> > > 
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > gstreamer-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> > 
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> -- 
> Olivier Crête
> olivier.crete at collabora.com
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel