f



Calling connect() spawns an unexpected thread on Windows

ACE VERSION: 5.7.0

    HOST MACHINE and OPERATING SYSTEM:
        Intel Core2 Duo E6550


    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
        Need to be able to run on several different platforms (x86,
PPC) and OS's (XP, RHEL 5, Wind River Linux 3.0)


    COMPILER NAME AND VERSION (AND PATCHLEVEL):
        On host machine, Microsoft Visual Studio 2005 Version
8.0.50727.762 (SP.050727-7600)


    BUILD METHOD USED:
        Visual Studio 2005


    AREA/CLASS/EXAMPLE AFFECTED:
        SOCK_Connector.cpp


    DOES THE PROBLEM AFFECT:
        COMPILATION? No
        LINKING? No
        EXECUTION? No


    SYNOPSIS:
        Calling connect() spawns an unexpected thread on Windows


    DESCRIPTION:
        It seems when I use the connect() function asynchronously for
the ACE_SOCK_Connector class, a thread is spawned unexpectedly.  It
also seems to be spawned from a low-level connect call but I can't
seem to figure out why.  What I am trying to do is create a client
program that first attempts to connect to a server that may or may not
be accepting connections.  This should happen asynchronously so that I
can do other things in my main thread.  When the server finally comes
up, the handle_output() function is executed and I can do what I need
to do appropriately.  See my pseudo-code below:

        ACE_SOCK_Stream stream;
        ACE_SOCK_Connector connector;
        connector.connect(stream, remoteAddr, &ACE_Time_Value::zero);

        ConnectionHandler* connectHandler = new
ConnectionHandler(stream, connector, remoteAddr);

        ACE_Reactor::instance()->register_handler(connectHandler,
ACE_Event_Handler::CONNECT_MASK);

        // Start main Reactor Event loop running in another thread
        ReactorEventLoop* _reactorThread = new ReactorEventLoop();
        _reactorThread->open(0);

        // Do other stuff here

        Based on the above code, I would like for my code to behave
the same no matter what platform i use (windows, linux, etc.)  Please
explain why this function is spawning a thread when it shouldn't.  I
ran my code on Red Hat and it seemed to not spawn a thread.  Is this a
bug in the behavior of ACE_SOCK_Connector's connect() method?  Should
this class, being a wrapper for Windows' low-level function calls,
make the appropriate low-level OS call in a way as not to spawn this
unexpected thread but still return an EWOULDBLOCK as expected?

    SAMPLE FIX/WORKAROUND:
        No workaround.  I can't pass a NULL value as the timeout value
to the connect() function since that will not let me register with the
Reactor and so, for now, I just deal with extra thread in my process. :
(


Thanks in advance for any help on this.
--Daynesh


0
dmangal
4/21/2010 3:05:15 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

1 Replies
4329 Views

Similar Articles

[PageSpeed] 58

Hi Daynesh,

Thanks for using the PRF.

>ACE VERSION: 5.7.0
>
>    HOST MACHINE and OPERATING SYSTEM:
>        Intel Core2 Duo E6550
>
>
>    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>        Need to be able to run on several different platforms (x86,
>PPC) and OS's (XP, RHEL 5, Wind River Linux 3.0)
>
>
>    COMPILER NAME AND VERSION (AND PATCHLEVEL):
>        On host machine, Microsoft Visual Studio 2005 Version
>8.0.50727.762 (SP.050727-7600)
>
>
>    BUILD METHOD USED:
>        Visual Studio 2005
>
>
>    AREA/CLASS/EXAMPLE AFFECTED:
>        SOCK_Connector.cpp
>
>
>    DOES THE PROBLEM AFFECT:
>        COMPILATION? No
>        LINKING? No
>        EXECUTION? No
>
>
>    SYNOPSIS:
>        Calling connect() spawns an unexpected thread on Windows
>
>
>    DESCRIPTION:
>        It seems when I use the connect() function asynchronously for
>the ACE_SOCK_Connector class, a thread is spawned unexpectedly.  It
>also seems to be spawned from a low-level connect call but I can't
>seem to figure out why.  What I am trying to do is create a client
>program that first attempts to connect to a server that may or may not
>be accepting connections.  This should happen asynchronously so that I
>can do other things in my main thread.  When the server finally comes
>up, the handle_output() function is executed and I can do what I need
>to do appropriately.  See my pseudo-code below:
>
>        ACE_SOCK_Stream stream;
>        ACE_SOCK_Connector connector;
>        connector.connect(stream, remoteAddr, &ACE_Time_Value::zero);
>
>        ConnectionHandler* connectHandler = new
>ConnectionHandler(stream, connector, remoteAddr);
>
>        ACE_Reactor::instance()->register_handler(connectHandler,
>ACE_Event_Handler::CONNECT_MASK);
>
>        // Start main Reactor Event loop running in another thread
>        ReactorEventLoop* _reactorThread = new ReactorEventLoop();
>        _reactorThread->open(0);
>
>        // Do other stuff here
>
>        Based on the above code, I would like for my code to behave
>the same no matter what platform i use (windows, linux, etc.)  Please
>explain why this function is spawning a thread when it shouldn't.  I
>ran my code on Red Hat and it seemed to not spawn a thread.  Is this a
>bug in the behavior of ACE_SOCK_Connector's connect() method?  Should
>this class, being a wrapper for Windows' low-level function calls,
>make the appropriate low-level OS call in a way as not to spawn this
>unexpected thread but still return an EWOULDBLOCK as expected?

As far as I know, ACE_SOCK_Connector doesn't spawn any threads in its
connect() method, which just calls ACE_OS::connect() in
OS_NS_sys_socket.inl, which just does this:

  ACE_SOCKCALL_RETURN (::connect ((ACE_SOCKET) handle,
                                  addr,
                                  (ACE_SOCKET_LEN) addrlen), int, -1);

which does whatever the underlying OS does to connect a socket.  I
have several questions:

.. What makes you think that a separate thread is spawned?

.. What part of the code (e.g., ACE or the OS) do you think it spawning
  a thread?  If it's not part of the ACE code, then you need to check
  how the OS works.

.. Have you traced this with the debugger to see what's going on and
  where the thread is purportedly being spawned?
  
Thanks,
  
  Doug
-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt@vanderbilt.edu
0
schmidt
4/21/2010 7:01:11 PM
Reply: