[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-datatype-dev
Subject:    [datatype-dev] RE: crash/hang on exit with dtdrplin
From:       Sujeet Kharkar <skharkar () real ! com>
Date:       2011-07-11 0:53:35
Message-ID: 766B5A29D28DA442AB229AAEE2AFC445084CA5424C () SEAMBX ! corp ! real ! com
[Download RAW message or body]

Looks good.

--Sujeet

________________________________________
From: Jamie Gordon
Sent: Sunday, July 10, 2011 11:54 AM
To: datatype-dev; Tools-dev@real.com
Subject: CR: crash/hang on exit with dtdrplin

Synopsis
========
Fixes a crash one exit and occasional hang on close with dtddrplin.

NOTE: prod14 only until the necessary updates are ready for to the
non-windows threaded callback manager and I've had a chance to
test synchronous mode.

Branches: PRODUCER_14_0_RN
Suggested Reviewer: anyone


Description
===========
dtdrplin is calling the response's OnTerminate way too soon - unless
Close is called in Stopped state, in which case it never calls back to
OnTerminate.

OnTerminate is being called on OnTermination from the source. But that
is always too soon - not only is the dtdrplin thread not terminated
yet, but its network thread (if applicable), MediaEngine and associated
threads, etc. are not closed and the dtdr engine has not even stopped,
closed the fileformat, etc.

This naturally causes problems - for instance if the calling process is
going to exit when the dtdriver is done, it has no idea when it is safe
to do so. OnTerminate needs to happen when it really is completely
terminated!

In cases where it is in Stopped state when the caller tries to close,
there is no OnTermination to be done, so OnTerminate does not ever
happen.

Also, calling OnTerminate from OnTermination clearly renders moot all
the special handling going on that is trying to allow the caller to
re-open for another file/URL, but I did not test whether this change
completely fixes that case.

Change is to wait until the engine's Drive has returned (which means
the engine is stopped) and if we are closing or get a close event as
the next input (rather than another Open->Drive), signal back to the
main calling thread to shut everything down, close the dtdriver thread,
and call back to the response. Or in case Close is called while already
Stopped, then do those things right there.


Files Affected
==============
datatype/tools/dtdriver/dtdrplin/cbmgr.cpp
datatype/tools/dtdriver/dtdrplin/cbmgr.h
datatype/tools/dtdriver/dtdrplin/datatypedr.cpp
datatype/tools/dtdriver/dtdrplin/messages.h
datatype/tools/dtdriver/dtdrplin/platform/win/thrdcbmgr.cpp
datatype/tools/dtdriver/dtdrplin/platform/win/thrdcbmgr.h
datatype/tools/dtdriver/dtdrplin/pub/datatypedr.h


Testing Performed
=================
Close during 'playback'
Natural close at end of stream
Engine natural close on headers ready in ProcessHeadersOnly case

Platforms Tested: win32-i386-vc9
Build verified: win32-i386-vc9


QA Hints
===============

Test stopping during decode, stopping during initialization/
timeout/retry, running to stream end, and -psi.
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev

[prev in list] [next in list] [prev in thread] [next in thread]