Suspending a method execution
Bing Zhang
bzhang@sohar.com
Thu, 05 Mar 1998 11:46:58 -0800
--------------046AC5641D0E2A4080E8AD15
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
I think the article Sai-Lai posted in last June is outdated or the wording
there is confusing.
>From the souce code of omniORB 2.4.0, I see one thread blocking for
request. When request comes in, it creates a new socket and spawn a new
thread called worker and passes the new thread the newly created socket.
After that the original thread goes back blocking on accept() for new
request. The original thread does not do any unmarshaling. The new thread
calles GIOP_S::dispatch(), does partial marshing and call the server side
dispatcher in the skeleton code.
If you set tracelevel to 20, you will see the printouts of these thread
activities.
Bing
Gary D. Duzan wrote:
> In Message <34FDAB02.5DBF5581@tts.dowjones.com> ,
> Kaisheng Du <kxd1483@tts.dowjones.com> wrote:
>
> =>Gary D. Duzan wrote:
> =>
> =>> In Message <34F70B6E.9B3@c-lab.de> ,
> =>> Jan Lessner <jan@c-lab.de> wrote:
> =>>
> =>> =>Hello all
> =>> =>A while ago I learned that omniORB creates a separate thread for
> =>> every
> =>> =>single implementation object for its request dispatching.
> =>>
> =>> The basis for your question is flawed. This is not, in fact, the
> =>> threading model used in OmniORB. Rather, it uses a thread-per-client-
> =>> connection model. There can be from zero to an arbitrarily large
> =>> number
> =>> of threads associated with an implementation object at any given time,
> =>>
> =>> depending on the number of clients operating on it. For details see
> =>> the
> =>> documentation with OmniORB 2.4.0, the chapter on Connection
> =>> Management,
> =>> and the section entitled The Model.
> =>
> =>It only says that a new connection will be set up if concurrent calls
> =>are made to the server. It didn't imply that
> =>the server will look up who is calling and give the caller the thread
> =>belonging to him, if it exists. It seems me that
> =>if the same client tries to make two calls back to back, OmniORB may
> =>create two different connections to the server.
>
> Right. Generally you have one thread waiting for new connections
> which starts one new thread for each IIOP connection. If the client
> decides that it needs another connection it can start another, but the
> server just treats it as any other new connection. The
> client-connection server threads actually block on the connection,
> waiting for incoming requests. If it gets one, the thread is used to
> unmarshall and dispatch it. Since it is a block/receive/execute/reply
> loop for each client-connection thread on the server, there is no need
> to "look up who is calling" for it to reuse the thread.
> The paragraph from the doc you really want to look at is:
>
> On the client side of a connection, the thread that invokes on
> a proxy object drives the IIOP protocol directly and blocks on
> the connection to receive the reply. On the server side, a
> dedicated thread blocks on the connection. When it receives a
> request, it performs the up-call to the object and sends the
> reply when the upcall returns. There is no thread switching
> along the call chain.
>
> Sai-Lai posted a pretty good message on this subject to the list a
> while back, as well. It is available from the list archives at:
>
> http://www.orl.co.uk/omniORB/archives/1997-Jun/0048.html
>
> Gary Duzan
> GTE Laboratories
--
------------------------------------------------------------------
Bing Zhang bzhang@sohar.com | Sohar Inc. |
Tel: (213)653-4717 X 118 | 8421 Wilshire Blvd., Suite 201 |
Fax: (213)653-3624 | Beverly Hills, CA 90211-3204 |
--------------046AC5641D0E2A4080E8AD15
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit
<HTML>
I think the article Sai-Lai posted in last June is outdated or the wording
there is confusing.
<P>From the souce code of omniORB 2.4.0, I see one thread blocking
for request. When request comes in, it creates a new socket and spawn a
new thread called worker and passes the new thread the newly created socket.
After that the original thread goes back blocking on accept() for new request.
The original thread does not do any unmarshaling. The new thread calles
GIOP_S::dispatch(), does partial marshing and call the server side dispatcher
in the skeleton code.
<P>If you set tracelevel to 20, you will see the printouts of these thread
activities.
<P>Bing
<BR>
<P>Gary D. Duzan wrote:
<BLOCKQUOTE TYPE=CITE>In Message <34FDAB02.5DBF5581@tts.dowjones.com>
,
<BR> Kaisheng Du <kxd1483@tts.dowjones.com> wrote:
<P>=>Gary D. Duzan wrote:
<BR>=>
<BR>=>> In Message <34F70B6E.9B3@c-lab.de> ,
<BR>=>> Jan Lessner <jan@c-lab.de> wrote:
<BR>=>>
<BR>=>> =>Hello all
<BR>=>> =>A while ago I learned that omniORB creates a separate thread
for
<BR>=>> every
<BR>=>> =>single implementation object for its request dispatching.
<BR>=>>
<BR>=>> The basis for your question is flawed. This is
not, in fact, the
<BR>=>> threading model used in OmniORB. Rather, it uses a thread-per-client-
<BR>=>> connection model. There can be from zero to an arbitrarily large
<BR>=>> number
<BR>=>> of threads associated with an implementation object at any given
time,
<BR>=>>
<BR>=>> depending on the number of clients operating on it. For details
see
<BR>=>> the
<BR>=>> documentation with OmniORB 2.4.0, the chapter on Connection
<BR>=>> Management,
<BR>=>> and the section entitled The Model.
<BR>=>
<BR>=>It only says that a new connection will be set up if concurrent calls
<BR>=>are made to the server. It didn't imply that
<BR>=>the server will look up who is calling and give the caller the thread
<BR>=>belonging to him, if it exists. It seems me that
<BR>=>if the same client tries to make two calls back to back, OmniORB
may
<BR>=>create two different connections to the server.
<P> Right. Generally you have one thread waiting for new connections
<BR>which starts one new thread for each IIOP connection. If the client
<BR>decides that it needs another connection it can start another, but
the
<BR>server just treats it as any other new connection. The
<BR>client-connection server threads actually block on the connection,
<BR>waiting for incoming requests. If it gets one, the thread is used to
<BR>unmarshall and dispatch it. Since it is a block/receive/execute/reply
<BR>loop for each client-connection thread on the server, there is no need
<BR>to "look up who is calling" for it to reuse the thread.
<BR> The paragraph from the doc you really want to look at
is:
<P> On the client side of a connection,
the thread that invokes on
<BR> a proxy object drives the
IIOP protocol directly and blocks on
<BR> the connection to receive
the reply. On the server side, a
<BR> dedicated thread blocks
on the connection. When it receives a
<BR> request, it performs the
up-call to the object and sends the
<BR> reply when the upcall returns.
There is no thread switching
<BR> along the call chain.
<P> Sai-Lai posted a pretty good message on this subject to
the list a
<BR>while back, as well. It is available from the list archives at:
<P> <A HREF="http://www.orl.co.uk/omniORB/archives/1997-Jun/0048.html">http://www.orl.co.uk/omniORB/archives/1997-Jun/0048.html</A>
<P>
Gary Duzan
<BR>
GTE Laboratories</BLOCKQUOTE>
<PRE>--
------------------------------------------------------------------
Bing Zhang bzhang@sohar.com | Sohar Inc. |
Tel: (213)653-4717 X 118 | 8421 Wilshire Blvd., Suite 201 |
Fax: (213)653-3624 | Beverly Hills, CA 90211-3204 |</PRE>
</HTML>
--------------046AC5641D0E2A4080E8AD15--