Locking problem

Hi,

we have written a quite huge app with cp 2.2.1
This is a port of a multi tier Windows App.

The flow of computation is:
1.) cherrypy handles the requests.
2.) Pythoncode in cp calls legacy code in a windows dll. We
use boost
python as the object wrapper.
3.) The DLL calls a none inproc COM/DCOM server (could also
sit on a
different machine)
4.) The DLL cames back with a result (sometimes directly
HTML or XML)
and cp returns the response.

Everything works quite fine for most situations and with few
users.

What we have observed with many users and in one recursive
situation
is this:
1.) During computation in the DLL the python interpreter is
not able
to give control to other threads.  This means that requests
from other
users must wait until the dll code returns.
2.) If the COM/DCOM object calls the cp-webservice
recursively (with
e.g. IServerXMLHTTPRequest) a deadlock is created. cp waits
for the
DLL to return, which waits for cp to receive the GET request
->
deadlock.

Problem 2 can be solved in many ways but is a indicator for
me that
(lengthly) computations in the dll lock the hole system.

Now my questions:
Are my interpretations correct?
Does a port to cp 3 help?
Is there a way to set up CP to fork independent processes
instead of
using a thread pool?

Thank you very much for any help!

Marcus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Marcus wrote:
> we have written a quite huge app with cp 2.2.1
> This is a port of a multi tier Windows App.
> 
> The flow of computation is:
> 1.) cherrypy handles the requests.
> 2.) Pythoncode in cp calls legacy code in a windows
dll. We use boost
> python as the object wrapper.
> 3.) The DLL calls a none inproc COM/DCOM server (could
also sit on a
> different machine)
> 4.) The DLL cames back with a result (sometimes
directly HTML or XML)
> and cp returns the response.
> 
> Everything works quite fine for most situations and
with few users.
> 
> What we have observed with many users and in one
recursive situation
> is this:
> 1.) During computation in the DLL the python
interpreter is not able
> to give control to other threads.  This means that
requests from other
> users must wait until the dll code returns.
> 2.) If the COM/DCOM object calls the cp-webservice
recursively (with
> e.g. IServerXMLHTTPRequest) a deadlock is created. cp
waits for the
> DLL to return, which waits for cp to receive the GET
request ->
> deadlock.
> 
> Problem 2 can be solved in many ways but is a indicator
for me that
> (lengthly) computations in the dll lock the hole
system.
> 
> Now my questions:
> Are my interpretations correct?

Seems somewhat reasonable, although I'm not really sure
about why the
deadlock occurs--is the IServerXMLHTTPRequest re-using the
same
webserver thread, or what? A funky situation indeed.

> Does a port to cp 3 help?

Not in any way I can think of. You should move to CP 3 for
speed and/or
to make extensions to the core more easily.

> Is there a way to set up CP to fork independent
processes instead of
> using a thread pool?

No, but there are plenty of ways to move your DLL/COM calls
to a
separate process and use some sort of IPC to negotiate the
request/response. That should solve both problems.


Robert Brewer
System Architect
Amor Ministries
fumanchuamor.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Apr 18, 7:48 am, Marcus <marcus.sch...gmx.net> wrote:
> Hi,
>
> we have written a quite huge app with cp 2.2.1
> This is a port of a multi tier Windows App.
>
> The flow of computation is:
> 1.) cherrypy handles the requests.
> 2.) Pythoncode in cp calls legacy code in a windows
dll. We use boost
> python as the object wrapper.
> 3.) The DLL calls a none inproc COM/DCOM server (could
also sit on a
> different machine)
> 4.) The DLL cames back with a result (sometimes
directly HTML or XML)
> and cp returns the response.
>
> Everything works quite fine for most situations and
with few users.
>
> What we have observed with many users and in one
recursive situation
> is this:
> 1.) During computation in the DLL the python
interpreter is not able
> to give control to other threads.  This means that
requests from other
> users must wait until the dll code returns.

Which is exactly what one would expect if at the point the
call is
made into the DLL the Python GIL is not released. You should
check
your wrapper code for the DLL to see if it uses
Py_BEGIN_ALLOW_THREADS
and Py_END_ALLOW_THREADS around the DLL call. These macros
ensure that
the Python GIL is released for the code that is between
them. Note
that you can't in general manipulate any Python data
structures while
the Python GIL is not held.

Graham

> 2.) If the COM/DCOM object calls the cp-webservice
recursively (with
> e.g. IServerXMLHTTPRequest) a deadlock is created. cp
waits for the
> DLL to return, which waits for cp to receive the GET
request ->
> deadlock.
>
> Problem 2 can be solved in many ways but is a indicator
for me that
> (lengthly) computations in the dll lock the hole
system.
>
> Now my questions:
> Are my interpretations correct?
> Does a port to cp 3 help?
> Is there a way to set up CP to fork independent
processes instead of
> using a thread pool?
>
> Thank you very much for any help!
>
> Marcus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---