Re: [Zope-dev] performance tuning of ZODB
Leonardo Rochael Almeida [EMAIL PROTECTED] writes: Hi Syver, Please add this issue to the Collector, including the test (prefereably without the twisted bits) Eh, what is the Collector? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] What do we want to bring from CVS to Subversion
Jim Fulton wrote: I'm working on the cvs to subversion conversion for the ZODB, Zope 2, and Zope 3 projects. I'm currently doing the conversion of the full history with tags and branches. This is taking a long time and creating a huge repository, which is OK, but, do we really need that much history? I see 3 options: 1. Convert the full history with branches. This will create a rather large and complex repository. 2. Convert the mainline history, but leave off the branches. 3. Start with a clean slate and simply import the current head. Note that, for Zope 2 and ZODB, current maintenance branches will remain in CVS. I think that option 2 provides a nice compromise. The main disadvantage of it is that it will leave current development branches high and dry. I'm not sure how big an issue this is. In theory, these could be committed to the subversion heav via patch files. Thoughts? I'm going to go with option 2. We won't lose anything, as we'll still have the existing tag and branch data in CVS as a permanent record. Just before conversion, I'll also tag the head. This will be useful for computing patch sets for open CVS workspaces and development branches. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] performance tuning of ZODB
[Leonardo Rochael Almeida] Please add this issue to the Collector, including the test (prefereably without the twisted bits) [Syver Enstad] Eh, what is the Collector? The zope.org Collectors are here: http://www.zope.org/Collectors/ and you want the Zope Collector: http://zope.org/Collectors/Zope/ It's where bug (or issue) reports are stored and managed. Maling lists don't work for this purpose. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] RE: [ZODB-Dev] Subversion repository layout
Kapil Thangavelu wrote: sigh.. debating over what the book says isn't very productive. my conclusions at the end of my previous email, namely that what this layout will accomplish for the zopeorg repository in terms of avoiding renames of checkouts will likely be fairly limited in pratice, still win me out against deviating from the standard layouts. I tried to understand this sentence a few, but I don't get it yet. So, are you saying you think we *shouldn't* use a custom layout and thus stick with the 'default' svn layout, or are you saying you think we should deviate from the default svn layout? Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope3-dev] RE: [ZODB-Dev] Subversion repository layout
[Kapil Thangavelu] [snip debating over what the book says] sigh.. debating over what the book says isn't very productive. That's for sure wink. my conclusions at the end of my previous email, namely that what this layout will accomplish for the zopeorg repository in terms of avoiding renames of checkouts will likely be fairly limited in pratice, still win me out against deviating from the standard layouts. I think your points about stitching stuff together are crucial, since a lot of that indeed occurs in the Zope world. You have svn experience too, while I don't, so I'm happy to yield to that. The other crucial thing is that we document clearly what we're doing. I said before that newcomers to svn won't understand the alternative structures, and I still believe that. By sheer coincidence, someone on comp.lang.python today posted this: I'm experimenting with svn. What is the best way to set up the original project, anticipating importing to a truck-and-branch world? When I start I have: myproject/ doc/ mypackage/ stable.py changing.py test/ go_test To do branches, I think I'm supposed to get to end up with: myproject/ trunk/ doc/ mypackage/ stable.py test/ go_test branches/ branch1/ mypackage/ changing.py test/ go_test ... If that demonstrates a lack of understanding of how svn truly works, what that really demonstrates is that *of course* newcomers to svn don't understand how it truly works, and I think it's hard to come away from a first pass over the svn book without believing this specific directory structure is more magical than it really is. monkey-see-monkey-do-is-a-tough-default-to-overcome-ly y'rs - tim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope Book at ZopeWiki.org
Yeah, this is exactely what I would need. Maybe I could ask someone to install this for me. Mmmhh, ... Hi Stephan.. I'll look into installing it on zopewiki for experiments. If someone wants to enable it on zope.org as well I will support. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?
+1 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Change in repository approach to software sharing
[Jim Fulton] The Zope project includes a number of interrelated subprojects, such as: - Zope 2 - Zope 3 - ZODB - ZConfig Software from the ZODB and ZConfig projects are shared by Zope 2 and Zope 3. Note that ZODB also depends on ZConfig. We want this sharing to be very convenient for people working on Zope 2 and Zope 3. We don't want users of the Zope 2 and Zope 3 repository to have to do separate checkouts for ZODB and ZConfig. CVS supports such software sharing through it's module system. The module system has some flaws, so we use symbolic links instead. In a response to: http://dev.zope.org/Zope3/MovingSCMToSubversion John Belmonte has suggested that Zope 2 and Zope 3 should depend on specific versions of shared packages, rather than on the head. I'm inclined to agree. Didn't we endure a lot of pain over the last year to get away from that model? At one point there were 7 lines of ZODB I was wrestling with every day. For example, there was the ZODB 3.1 branch, which in theory corresponded to the Zope 2.6 branch, but in practice never matched it. Life got much better (for both Zope 2.6 maintenance and ZODB 3.1 maintenance) when we abandoned the ZODB3-3_1-branch branch of ZODB3 and did all ZODB 3.1 maintenance directly on the Zope-2_6-branch branch of Zope. Likewise for ZODB3-3_2-branch versus Zope-2_7-branch: the former was abandoned, and life got better for everyone because of that. Currently the HEAD of the ZODB module is the same as the HEAD view of ZODB when viewed from the Zope and Zope3 modules, which isn't a pure win, but isn't a pure loss either. People working on ZODB and ZConfig have to test their changes against both Zope 2 and Zope 3 to avoid breakage. I don't see that this part can change, no matter how names are shuffled. This is very burdensome That part either -- all the tests in all contexts still need to be run. and causes much pain when they get it wrong. Ditto, although you're (re)introducing mechanism that alleviates this at the cost of increasing the number of ZODB snapshots in active use. Fortunately, subversion provides a mechanism for sharing specific revisions. We'll be able to have the convenience of getting ZODB and ZConfig (and other shared software) when we do a checkout *and* we'll be able to control what parts we get. To see how this will work, we'll look at ZConfig as an example (because it has a single package) of reusable software that we will include in Zope 3. In the repository, we'll have a top-level Zope3 project directory, with the standard svn subdirectories trunk, branches, and tags. We'll also have a top-level ZConfig project directory. The trunk of the ZConfig Python package will be in ZConfig/trunk/src/ZConfig. If we create a tag T1 of ZConfig, then the Python package for that tag will be in ZConfig/tags/T1/src/ZConfig. Now, when we set up the Zope 3 repository, we will create the ZConfig package in Zope 3 by copying a *tag* from the ZConfig project: svn copy svn+ssh://svn.zope.org/repos/ZConfig/tags/T1/src/ZConfig \ svn+ssh://svn.zope.org/repos/Zope3/trunk/src/ZConfig -m 'Bring ZConfig T1 into main branch' Then, whenever someone checks out the Z3 trunk, they'll get the ZConfig from T1. I don't yet know enough about svn to guess how the next step works: since ZODB all by itself depends on ZConfig, presumably similar stitching of ZConfig will take place in the top-level ZODB project. Now when we go on to stitch ZODB into Z3, how will ZODB's attempt to stitch in its own version of ZConfig play with Z3's attempt to stitch in T1 above? I'm not picturing how this works. Maybe it's simple! If we need to, we can even make Zope3-local changes to ZConfig. That would bloat ZConfig maintenance headaches exponentially. I'm confident of that, because of ZODB experience with (at least) 7 concurrently active ZODB snapshots -- it's simply intractable to keep straight what should and shouldn't get cross-ported across this set; mistakes and oversights are as much the norm as the exception then; the non-ZODB people doing stitching of ZODB into their projects won't be confident about exactly which tag they should stitch in; expediency will cause them to stitch in whatever seems to work at the time; and then the latter becomes an active snapshot that needs to be maintained too. Don't make Zope3-local changes to ZConfig or ZODB, though, and at least that nest of rats can be sidestepped. Later, we may decide to upgrade the Zope 3 head to use ZConfig tag 3. Ya, and the Zope head may decide to use ZConfig tag 44, while the Zope 2.8 maintenance branch decides to use ZConfig tag 37 despite that ZConfig 3.3.1 (which is supposed to go out with the next Zope 2.8 release) is actually released at tag 39. The dark side of flexibility is that it creates that many more ways to get out of synch. At that point, we can recopy from the tag, or we can merge changes
[Zope-dev] ATTENTION! cvs to subversion transition tomorrow
Tomorrow, as planned. I'm going to move the main development branches for Zope 2, Zope 3, and ZODB to subversion. I will start the move at 10am US/Eastern time tomorrow. I plan to be done before 5pm US/Eastern time. During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions. Speaking of subversion instructions, I'll be sending some later today. If you want to do writable subversion checkouts, you'll need to submit a version 1.1 contributor's agreement (if you haven't already). The contributor's agreement can be found at: http://dev.zope.org/DevHome/CVS/Contributor.pdf You can print and then send the filled out and signed agreement to us in one of 3 ways: - Ordinary mail to: Zope Corporation, 513 Prince Edward Street Fredericksburg, VA, USA, 22401 - Fax to 1.703.995.0412 - Email a scanned form to: [EMAIL PROTECTED] Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope Book at ZopeWiki.org
On Tuesday 27 April 2004 14:42, Simon Michael wrote: Yeah, this is exactely what I would need. Maybe I could ask someone to install this for me. Mmmhh, ... Hi Stephan.. I'll look into installing it on zopewiki for experiments. If someone wants to enable it on zope.org as well I will support. Cool, I am willing to test some chapters of the cookbook with it. I have a whole lot of customized commands, so they would need to play nicely with ZWiki for LaTeX. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] is threading in zope really useful ?
greetings, I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ? Any thoughts ? your ideas are much appreciated ty sathya ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Policy for Collector-Issues 545 and 1217?
here's the patch I'd have attached to
http://zope.org/Collectors/Zope/1217
if the collector could collect
--
Jamie Heilman http://audible.transient.net/~jamie/
Paranoia is a disease unto itself, and may I add, the person standing
next to you may not be who they appear to be, so take precaution.
-Sathington Willoughby
--- lib/python/App/dtml/manage.dtml 22 Dec 2002 17:53:57 - 1.10
+++ lib/python/App/dtml/manage.dtml 27 Apr 2004 21:14:33 -
@@ -19,14 +19,14 @@
dtml-else
frameset rows=34, *
/dtml-if
- frame src=dtml-URL1;/manage_top_frame name=manage_top_frame
+ frame src=manage_top_frame name=manage_top_frame
marginheight=0 scrolling=no/
/dtml-if
frameset cols=175,*
-frame src=dtml-URL1;/manage_menu name=manage_menu
+frame src=manage_menu name=manage_menu
marginwidth=2 marginheight=2 scrolling=auto/
-frame src=dtml-URL1;/manage_workspace name=manage_main
+frame src=manage_workspace name=manage_main
marginwidth=2 marginheight=2 scrolling=auto/
/frameset
--- lib/python/App/dtml/manage_tabs.dtml4 Nov 2003 16:52:24 - 1.14
+++ lib/python/App/dtml/manage_tabs.dtml27 Apr 2004 21:14:33 -
@@ -59,7 +59,7 @@
align=centerfont face=Verdana, Arial, Helvetica
size=1 color=#00nbsp;a dtml-if s_item.get('action')
href=dtml-action;dtml-else
- href=dtml-URL1;/dtml-if
+ href=dtml-var REQUEST.URL1 html_quote/dtml-if
dtml-if s_item.get('target') target=dtml-target;/dtml-if
span style=color: #00;strongdtml-var s_item['label']
/strong/span/anbsp;/font/td
@@ -68,7 +68,7 @@
align=centerfont face=Verdana, Arial, Helvetica
size=1 color=#00nbsp;a dtml-if s_item.get('action')
href=dtml-action;dtml-else
- href=dtml-URL1;/dtml-if
+ href=dtml-var REQUEST.URL1 html_quote/dtml-if
dtml-if s_item.get('target') target=dtml-target;/dtml-if
span style=color: #00;strongdtml-var s_item['label']
/strong/span/anbsp;/font/td
--- lib/python/OFS/dtml/fileEdit.dtml 6 Jul 2003 10:43:53 - 1.9
+++ lib/python/OFS/dtml/fileEdit.dtml 27 Apr 2004 21:14:33 -
@@ -10,7 +10,7 @@
text type and small enough to be edited in a text area.
/p
-form action=dtml-URL1; method=post enctype=multipart/form-data
+form action=dtml-var REQUEST.URL1 html_quote method=post
enctype=multipart/form-data
table cellpadding=2 cellspacing=0 width=100% border=0
tr
td align=left valign=top
--- lib/python/OFS/dtml/findFrame.dtml 22 Dec 2002 17:53:59 - 1.3
+++ lib/python/OFS/dtml/findFrame.dtml 27 Apr 2004 21:14:33 -
@@ -5,12 +5,12 @@
/HEAD
FRAMESET ROWS=52%,*
dtml-if cv_ffaf
- FRAME SRC=dtml-URL1;/manage_findAdv NAME=findForm
+ FRAME SRC=dtml-var REQUEST.URL1 html_quote/manage_findAdv NAME=findForm
dtml-else
- FRAME SRC=dtml-URL1;/manage_findForm NAME=findForm
+ FRAME SRC=dtml-var REQUEST.URL1 html_quote/manage_findForm NAME=findForm
/dtml-if
MARGINWIDTH=2 MARGINHEIGHT=2 SCROLLING=auto
- FRAME SRC=dtml-URL1;/manage_findResult NAME=findResult
+ FRAME SRC=dtml-var REQUEST.URL1 html_quote/manage_findResult
NAME=findResult
MARGINWIDTH=2 MARGINHEIGHT=0 SCROLLING=auto
/FRAMESET
NOFRAMES
--- lib/python/OFS/dtml/findResult.dtml 19 Jan 2004 19:56:52 - 1.6
+++ lib/python/OFS/dtml/findResult.dtml 27 Apr 2004 21:14:34 -
@@ -60,13 +60,13 @@
td width=50%
div class=list-item
dtml-in name=results previous size=batch_size start=query_start
- strong a
href=dtml-URL;dtml-sequence-query;query_start=dtml-previous-sequence-start-number;lt;
Previous/a/strong
+ strong a href=dtml-var REQUEST.URL
html_quotedtml-sequence-query;query_start=dtml-previous-sequence-start-number;lt;
Previous/a/strong
dtml-elsenbsp;/dtml-in/div
/td
td align=right width=50%
div class=list-item
dtml-in name=results next size=batch_size start=query_start
- stronga
href=dtml-URL;dtml-sequence-query;query_start=dtml-next-sequence-start-number;Next
gt;/a/strong
+ stronga href=dtml-var REQUEST.URL
html_quotedtml-sequence-query;query_start=dtml-next-sequence-start-number;Next
gt;/a/strong
dtml-elsenbsp;/dtml-in/div
/td
/tr
--- lib/python/OFS/dtml/history.dtml22 Dec 2002 17:53:59 - 1.4
+++ lib/python/OFS/dtml/history.dtml27 Apr 2004 21:14:34 -
@@ -2,7 +2,7 @@
dtml-var manage_tabs
dtml-if manage_change_history
- form action=dtml-URL1; method=POST
+ form action=dtml-var REQUEST.URL1 html_quote method=POST
table width=100% cellspacing=0 cellpadding=2 border=0
tr class=list-header
@@ -10,7 +10,7 @@
div class=list-nav
dtml-if first_transaction
dtml-with expr=_(next=first_transaction*2-last_transaction)
-a
href=dtml-URL;?first_transaction:int=dtml.-next;last_transaction:int=dtml.-first_transaction;HistoryBatchSize:int=dtml.-HistoryBatchSize;lt;
Later Revisions/a
+a href=dtml-var REQUEST.URL
[Zope-dev] Re: [Zope3-dev] RE: [ZODB-Dev] Subversion repository layout
On Tue, 2004-04-27 at 10:27, Martijn Faassen wrote: Kapil Thangavelu wrote: sigh.. debating over what the book says isn't very productive. my conclusions at the end of my previous email, namely that what this layout will accomplish for the zopeorg repository in terms of avoiding renames of checkouts will likely be fairly limited in pratice, still win me out against deviating from the standard layouts. I tried to understand this sentence a few, but I don't get it yet. So, are you saying you think we *shouldn't* use a custom layout and thus stick with the 'default' svn layout, or are you saying you think we should deviate from the default svn layout? i'm saying we should probably stick with the default layout. why? because the primary benefit of the alternative layout is to avoid having to do a rename while checking out the trunk of a project, on checking out from branches or tags, this is required anyways. and in my experience most of the checkouts will likely be on release branches, and tags anyways. iotw. its of little benefit considering the disadvantages of moving from the default layout. cheers, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transition tomorrow
Jim Fulton wrote: Tomorrow, as planned. I'm going to move the main development branches for Zope 2, Zope 3, and ZODB to subversion. I will start the move at 10am US/Eastern time tomorrow. I plan to be done before 5pm US/Eastern time. During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions. Gr. The conversion is going to take longer than I planned. I'm going to start at 6am US/Eastern. I still hope to be done by 5pm. Speaking of subversion instructions, I'll be sending some later today. At this point, we have one main repository. Initially, this repository will include the Zope (Zope 2), Zope3, ZODB, ZConfig, zLOG, and zdaemon projects. I've set up a partial converion of these projects on svn.zope.org for you to play with tonight. You will be able to browse the repository at: http://svn.zope.org You will be able to do read-only anonymous checkouts like so: svn co svn://svn.zope.org/repos/main/project/trunk For example: svn co svn://svn.zope.org/repos/main/ZConfig/trunk To do a writable checkout (if you are a contributor who has submitted a version 1.1 contributor's agreement), you will use svn+ssh: svn co svn+ssh://svn.zope.org/repos/main/project/trunk Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: Policy for Collector-Issues 545 and 1217?
[Jamie Heilman] here's the patch I'd have attached to http://zope.org/Collectors/Zope/1217 if the collector could collect FYI, I attached the patch to the collector report (nothing magical -- it just worked for me). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] is threading within zope useful ?
greetings, I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ? Any thoughts ? your ideas are much appreciated ty sathya ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] is threading in zope useful ?
greetings, I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ? Any thoughts ? your ideas are much appreciated ty sathya ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] is threading in zope useful ?
[sathya] I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. The Python GIL (global interpreter lock) affects all code written in Python: only one thread at a time can interpret Python bytecodes in a given process. That's true in or out of Zope. Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ? No. The GIL effectively serializes threads doing pure computation in Python, but many pieces of the Python implementation release the GIL around calls to known-threadsafe C libraries. The most important examples of that are I/O, of many kinds. For example, if a Python thread opens a socket, the GIL is released around the C-level code that does the low-level socket open, which allows other Python threads to proceed in parallel (of course the thread that does the C-level socket open waits for the latter to finish; it reacquires the GIL after the socket operation is complete and it's ready to go back to interpreting Python bytecodes). Because Zope does a lot of network I/O, this form of parallelism can be very useful for it. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is threading in zope useful ?
Tim Peters wrote: tim thanks much for the explanation. some points below. [sathya] I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. [tim] No. The GIL effectively serializes threads doing pure computation in Python, but many pieces of the Python implementation release the GIL around calls to known-threadsafe C libraries. The most important examples of that are I/O, of many kinds. For example, if a Python thread opens a socket, the GIL is released around the C-level code that does the low-level socket open, which allows other Python threads to proceed in parallel (of course the thread that does the C-level socket open waits for the latter to finish; it reacquires the GIL after the socket operation is complete and it's ready to go back to interpreting Python bytecodes). Because Zope does a lot of network I/O, this form of parallelism can be very useful for it. [sathya] great ! If I understand correctly, if we had a zope process running on an smp linux machine and doing lots of RDBMS calls we would not be limited by the GIL. In essence threads running on multiple cpus would probably not have to wait on acquiring the GIL as most every page request results in a ZSQL method call which in turn would release the GIL. Therefore SMP may not be hindered by the GIL. That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux. please point out any flaws in my thought process . again thanks very much for putting it in persepective. it clears up some fog for us ! regards sathya ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
[Jim Fulton] ... You will be able to do read-only anonymous checkouts like so: svn co svn://svn.zope.org/repos/main/project/trunk For example: svn co svn://svn.zope.org/repos/main/ZConfig/trunk FYI, I tried that on Windows (XP), and it worked fine. One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). I'm not sure what to do about this. Best I can tell from the docs so far, svn wants a svn:eol-style property added to every line-oriented file, with value native in order to get platform-sane line-end conversions. The doc's explanation of the effect of that matches my understanding of what CVS does for all non-binary files, which is usually exactly right. I noticed that Fredrik Lundh complained about something similar here: http://effbot.org/zone/subversion.htm ... Properties are nice, but having to use three different commands to check in a text file from Windows is pretty annoying. Looks like svn *expected* us to do this by setting enable-auto-props during the intial imports, with a bunch of [auto-props] settings in a config file; like [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg I think we'll have to develop a standard set of config file settings like that for committers to add to their personal svn configs -- or can that be done on the server side? To do a writable checkout (if you are a contributor who has submitted a version 1.1 contributor's agreement), you will use svn+ssh: svn co svn+ssh://svn.zope.org/repos/main/project/trunk Is that supposed work already? All I've been able to get out of it is, e.g., C:\Codesvn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk szc2 svn: Connection closed unexpectedly where the error msg appears very quickly (usually well under a second). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is threading in zope useful ?
On Wed, 2004-04-28 at 03:41, sathya wrote: [sathya] great ! If I understand correctly, if we had a zope process running on an smp linux machine and doing lots of RDBMS calls we would not be limited by the GIL. In essence threads running on multiple cpus would probably not have to wait on acquiring the GIL as most every page request results in a ZSQL method call which in turn would release the GIL. Therefore SMP may not be hindered by the GIL. That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux. please point out any flaws in my thought process . SMP is not doing any good for you when not running multiple Python processes. The GIL doesn't work per CPU but for the whole system. You very likely will end up locking your CPUs 2-n on a N-way system due to the GIL. ZEO actually does the trick, but you should use CPU binding for the processes to make sure they won't affect other processors. Cheers, Christian ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
