This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSPLink 1.61.03 vs dsplink 1.65.00.02

Hi,

Can anyone tell me what are the new features of dsplink 1.65.00.02?. Is the problem on this link https://gstreamer.ti.com/gf/project/gstreamer_ti/tracker/?action=TrackerItemEdit&tracker_item_id=883 has been resolved?.

Thanks,

 

John

  • John,

    For the new features, upgrade and compatibility w.r.t previous releases etc, please look at the relevant sections in ReleaseNotes.pdf in $DSPLINK/doc

    To answer your specific query:

    Seeing a zombie process is a known behavior.Details below:

    Signal handling from a library is insufficient to cleanup after the application. The application writer must disable default DSPLink signal handling and write an application level signal handler which cleans up all application resources. The application level signal handler in the parent process must clean up all DSPLink resources as well as wait for all child processes to terminate. If the application does not register a signal handler and instead cleanup happens via DSPLink default signal handler in a child process, a zombie process may be seen.  The theory behind this is: When a child process terminates while its parent is calling a wait function, the child process vanishes and its termination status is passed to its parent via the wait call. If a child process terminates and the parent is not calling wait, the child process turns into a zombie process. The information about its termination such as whether it exited normally and, if so, what its exit status is would be lost. If the parent process does not call wait. Instead, when a child process terminates, is becomes a zombie process.  A zombie process is a process that has terminated but has not been cleaned up yet. It is the responsibility of the parent process to clean up its zombie children.  The wait functions do this, too, so it's not necessary to track whether your child process is still executing before waiting for it. Suppose, for instance, that a program forks a child process, performs some other computations, and then calls wait. If the child process has not terminated at that point, the parent process will block in the wait call until the child process finishes. If the child process finishes before the parent process calls wait, the child process becomes a zombie. When the parent process calls wait, the zombie child's termination status is extracted, the child process is deleted, and the wait call returns immediately.

    Please look at the section DSPLink and signals in the Release Notes for more details.

    Deepali