[vorbis-dev] Re: Possible fix for bug #14 (ogg123 -b memory leak)

[Jeff Squyres]

On Sun, 13 May 2001, Kenneth Arnold wrote:

> I had heard of pthreads working on a lot of things, and was going to
> go dig up your exact patch when I remembered pthreads. Doing the
> writer as a thread instead of a child process would be much more clean
> IMHO, but if there really are portability problems with doing it as a
> thread, I won't (or maybe #ifdef or conditionally compile a threaded
> implementation for those platforms that support pthreads, but that
> gets messy quickly).

I've been quiet on the list for quite a long time (...must
graduate!!!...), but I think it's well known that I'm a big fan of threads
(can't comment on any *BSD pthreads issues, though -- haven't really
looked into that).

IMHO, threads make certain types of tasks easier.  Of course, threads
introduce their own difficulties -- there's no such thing as a free lunch,
after all.  But these are typically application-dependant issues.  So
you'd need to compare in terms of what ogg123 specifically does (I'm not
really familiar with the ogg123 internals).

Here's some questions to ask:

- What happens now if [one of] the writer child process[es] die?  Do they
  all die?  Is this acceptable?  (because if one thread dies, they will
  all die)
- What IPC is ogg123 doing, exactly?  e.g.:
  - Can it easily be mapped to thread-to-thread queues?
  - Will you cut down on overhead by eliminating memory copies by passing
    pointers instead of copying in/out of the shared memory space?  Or
    is the data so small that the extra memory copies don't matter?
  - Can you take advantage of mutexes/semaphores/condition variables to
    utiulize blocking instead of spinning?  Do you want to?  (there is
    more initial overhead with these, but if you're going to wait for a
    long time, it costs less than spinning, particularly if the machine
    is not otherwise idle)
- Does the parent process have to manage its children processes?  i.e.,
  waitpid() and the like?  (that *may* be able to disappear, or it may
  just get replaced with the main thread doing essentially the same thing)
- Would ogg123 benefit from thread scheduling rather than process
  scheduling? (excluding Linux, of course)
- Are pthreads portable to mac? (or has the community decided not to
  support anything < OS X, which does have pthreads?  I haven't been
  following if any such decisions were made...)
- Does your debugger support threads?  You're already dealing with
  debugging in parallel (which can be painful); moving them to threads
  potentially allows the ability to use a single debugger (although gdb's
  support for threads is kinda crappy).

Of course, you can take threads out to the Nth degree and revamp the
application to fully utilize mulitple points of execution within a single
program (for example, I'm a big fan of hiding latency with threads;
whenever you need to do something that will block [such as fetching I/O],
just let some sub-thread do it and let the rest of the main program
continue -- or even have a thread pre-emtively do it so that the main
program never has to wait), but I'm guessing that that's not the goal
here.

Just my $0.02...

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.