WinStartApp question - OS2

This is a discussion on WinStartApp question - OS2 ; Hi folks, could it be, that WinStartApp() is blocking *ALL* threads of the calling process (probably by means of Enter / ExitCriticalSection) until the sub-process is up and running ? I see here strange buffer overruns in a multimedia streaming ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: WinStartApp question

  1. WinStartApp question

    Hi folks,

    could it be, that WinStartApp() is blocking *ALL* threads of
    the calling process (probably by means of Enter /
    ExitCriticalSection) until the sub-process is up and running ?

    I see here strange buffer overruns in a multimedia streaming
    application while attempting to start FireFox using this API.
    These do not occure, when DosStartSession() is used instead.
    However, DosStartSession() has the major disadvantage, that
    it does not allow to specify a startup directory.


    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  2. Re: WinStartApp question

    On Tue, 25 Dec 2007 17:25:46 UTC, "Ruediger Ihle"
    wrote:

    > Hi folks,
    >
    > could it be, that WinStartApp() is blocking *ALL* threads of
    > the calling process (probably by means of Enter /
    > ExitCriticalSection) until the sub-process is up and running ?
    >
    > I see here strange buffer overruns in a multimedia streaming
    > application while attempting to start FireFox using this API.
    > These do not occure, when DosStartSession() is used instead.
    > However, DosStartSession() has the major disadvantage, that
    > it does not allow to specify a startup directory.


    No, It depends on the current tie slice left over when you call
    WinStartApp().
    However when you call an API yor curret process will lost the critical
    Section anyway.

    So when you needs a criticasl section you should avoid to call any
    base, PM and WPS API as this will mostenly ends a critical section
    magically.

    However there is no guarantee when the new createsd session will
    start. It may be get CPU before WinStartSession comes back or some
    time later. When the new created session has higher priority than the
    thread creating it you can be sure that it will get CPU immediately
    else the current thread should exhause its timeslice before any other
    thread that is waiting for CPU gets a new timeslice.

    When you falls over an buffer overrun check the the thread that fills
    the buffer for mistakes on that.


    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2R Deutsch ist da!

  3. Re: WinStartApp question (solution)

    On Wed, 26 Dec 2007 21:22:03 UTC, "Herbert Rosenau"
    wrote:

    > When you falls over an buffer overrun check the the thread
    > that fills the buffer for mistakes on that.


    I think I've found the reason. I didn't mention, that the
    buffer overflow occures in a device driver from which one
    application thread is permanently acquiring data at a
    relatively high rate. In my first posting I wrote that the
    failure is only with WinStartApp() and not with
    DosStartSession(). This was not correct ! I can produce
    the very same kind of error using the DosStartSession() API.
    But it occures here only, it STARTDATA.InheritOpt is set
    to SSF_INHERTOPT_PARENT.

    This rang some bells. Maybe the system is temporary blocking
    access to file handles while it applies handle inheritance or
    the called application itself is messing with the inherited
    handle(s).

    And really: after adding OPEN_FLAGS_NOINHERIT to the DosOpen()
    call for the device driver, the problem went away. Now I can
    use both WinStartApp() and well as DosStartSession() without
    any side effects.



    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  4. Re: WinStartApp question (solution)

    Ruediger Ihle schrieb:
    > This rang some bells. Maybe the system is temporary blocking
    > access to file handles while it applies handle inheritance or
    > the called application itself is messing with the inherited
    > handle(s).
    >
    > And really: after adding OPEN_FLAGS_NOINHERIT to the DosOpen()
    > call for the device driver, the problem went away. Now I can
    > use both WinStartApp() and well as DosStartSession() without
    > any side effects.


    Oh! Good to know.

    The classical pattern, that threads of different priority must not share
    the same mutextes. (Unfortunately Theory)


    Marcel

+ Reply to Thread