sem_open behaviour

muny
2010-03-31
2013-05-23
  • muny
    muny
    2010-03-31

    Hello

    Could anyone tell me why i find this in SHM dir :
    4 -------  1 muny muny       16 2010-03-29 15:06 sem.sem_short_272xxxxx

    And why this fifo doesn't be closed after close bristol ?

    Is it normal behaviour ??

    Thanks for all

     
  • Nick Copeland
    Nick Copeland
    2010-03-31

    This is the default behavious: bristol will use a couple of semaphores to ensure that MIDI key events do not collide with audio activity. This looks like the cleanup is not always being handled well - did the application crash out?

    You can resolve this issue (and others) by rebuilding with '-disable-semaphore':

    ./configure -disable-semaphore && make clean
    make install

    This removes the semephore code which is bad practice for time sensitive audio apps anyway and replaces it with a couple of jack ringbuffers for midi message passing between the threads. It will become default behaviour in a later release when it has been tested a bit more. Now I always build with the ringbuffers for that reason.

    Hope that helps, kind regards, nick

     
  • muny
    muny
    2010-03-31

    thanks for your reply, ncopeland

    yes, i dont want to disable semaphore.

    no, the software dont crash, jack niput and oupt are correctly closed
    But stay in <defunc> state after closed.

    -> Is the reason why don't clean the sem fifo in shm ?

    If not pass the -enable-sem-open all work correctly off course. But not optimal too ?

    What could you advise to me ? not use sem-open, or use source before patch sem_open ? Use as it with the extremly minimal risk with many not closed in shm ?

    thanks for all
    best regards.

     
  • Nick Copeland
    Nick Copeland
    2010-03-31

    Ah, OK, the sem-open flag. This is not default as I don't like sem_open, I prefer sem_init however that has compatibility issues.

    My advice is actually to build with the -disable-semaphore option, using this semaphore/mutex is a bad idea for audio applications, they can cause lockout under specific circumstances. I made a lot of effort to ensure the typical errors were avoided (things like priority inversion for example) but the future code will remove the semaphore by default.

    If you build with semaphores disabled then the sem_open option has no effect - the code is not used anymore. If you are building on a typical Linux machine then you should not need the -enable-sem-open either.

    Kind regards, Nick

     
  • muny
    muny
    2010-03-31

    thanks for all
    best rebards