Re: Thread-safety in Pylons (Python?)
Kamil Gorlo wrote: On Thu, Mar 5, 2009 at 3:46 AM, Philip Jenvey pjen...@underboss.org wrote: http://effbot.org/pyfaq/what-kinds-of-global-value-mutation-are-thread-safe.htm Yeah, this site is a bit ambigous, e.g. Operations that replace other objects may invoke those other objects’ __del__ method when their reference count reaches zero, and that can affect things. This is especially true for the mass updates to dictionaries and lists. When in doubt, use a mutex! But before that statement author said that following operations are atomic: D[x] = y D1.update(D2) where x,y are objects and D1 and D2 are dict. So how this could be true? I believe the adjective atomic applies only to the affect on D or D1, in this case, and given the comment about __del__ I think it probably doesn't apply even to the .update() case (unless D2 has length 1). But even if we assume that getitem and setitem on dict are atomic (on 'steady' value only? which means primitives?). How to solve problem which I am facing now: I want to start another thread T1 in my Pylons App (manually, not Paste#http worker) and have some global dict which all http workers will read. But T1 periodically will update this dictionary (in fact all he want to do is to swap this global dict with local dict which was prepared during his work). In this dict I will have Python primitives (other dicts too) and simple classes which act only as 'structs'. Do I need lock? If by swap you simply mean you will be rebinding the global name to a new dictionary, then the rebinding itself will certainly be atomic. One the other hand, if the various worker threads access this global name more than once in a request (or session, or whatever) then you will certainly have problems as they would use the old dictionary for part of the request then use the new one. If they simply grab a local reference to the global name (possibly storing it in their request object, or session, depending on what you need) when first needed, and thereafter access it only from there, I can't see how you'd have any problems (ignoring issues involving changes to various contained items, which might be shared if you haven't ensured they are not). I think if you aren't sure yet what will work, post some pseudo-code showing what you would do if you were to ignore thread-safety issues. Also note that use of the Queue module is a very common step to dealing with thread-safety issues, generally resulting in most or all potential problems just going away. If that could work for you it's probably the best bet. -- Peter Hansen, P.Eng. Engenuity Corporation 416-617-1499 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
Cliff Wells wrote: Anyway, I think we've gone way OT for long enough. We can continue offlist if you like. While it may be off-topic** I want to say I've found the background discussion from everyone involved (who are all more experienced and knowledgeable in this area than I am) to be very interesting and educational and valuable. I'm running Pylons direct for a beta site, and behind lighttpd for some others, but this is one of the few threads in which I've read all the content lately, and I hope it isn't really considered so off-topic that you feel you have to stop. And if you do, well, thanks for all the fish while it lasted, anyway. -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pudge Doc Working?
On 8/30/07, Aaron R [EMAIL PROTECTED] wrote: In another message string it was mentioned that James was working on a replacement for Pudge? Any info on this, i would potentially be interested in helping as I have a desire for documentation system. We're very interested in this whole area too, as we have a number of projects with inadequate documentation and want to automate the whole extraction of docs from docstrings plus building HTML docs from text files. I've looked a number of times and haven't found anything resembling a fully functional system for this, and the few that come close look like crap. The best I've seen so far is the hodge-podge of stuff that's in the sqlalchemy project, down in the doc/build folder. As you can tell from the online docs, it's pretty darn good looking, and the tool works fine when run here on the sqlalchemy trunk, which is more than I can say for other packages. (Even pydoc, part of the stdlib, gives errors here, and I have the same troubles with pudge that everyone else seems to have.) Someone suggested pydoctor (http://codespeak.net/~mwh/pydoctor/) recently, but it's got some of the same issues, with its major advantage being that it appears to be under active development which is more than can be said of most packages. A disadvantage though is that at least on first glance it appears to focus solely on docstrings and not on standalone documentation. I'm at the point I probably will start to build something home-grown here, probably trying to model it on the sqlalchemy concepts (but without the ties to Mako and Myghty that seem to be in there), and probably using ReST instead of Markdown or something less official in the Python community. Of course, if there really _is_ something out there that others find just works, please please point me to it. (Aaron, you said after the above that you got Pudge working. Does it actually generate the kind of output you want?) -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 'c' variable between redirects
Evert Rol wrote: As mentioned, I'm using the g variable (removing the attribute when not needed), not session. Which one would be better? Is g perhaps tied to the application, ie if multiple users use it, they all use the same g variable, but session is still (browser/ip-address) user- dependent? Sorry, I'm still a newbie, so I'm not t0o clear on this. You definitely don't want to use g, which is truly application-global. That means separate threads see the same g, and certainly separate requests even if they come from different users. Sessions are tied to the user, which means (roughly) that regardless of threads you'll get the correct information about the user. Everything else you're doing sounds quite reasonable and clean and nice for the user, so if you just switch to sessions you'll be quite reasonable and clean and nice *and* safe. ;-) -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On 8/24/07, Pekka Jääskeläinen [EMAIL PROTECTED] wrote: Apache 2.2 has a mod_proxy_balancer. If performance is a concern, you should go with the CherryPy WSGI server. use = egg:PasteScript#cherrypy instead of use egg:Paste#httpserver This didn't work, I changed the line use = egg:Paste#http to use egg:Paste#cherrypy Even though I just installed CherryPy, I got error: Note it's egg:PasteScript in the above, not just egg:Paste. -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
PrefixMiddleware breaks setup-app (was Re: PrefixMiddleware breaks nosetests)
I'm encountering the same problem, under slightly different conditions
that lead me to think this is a bug, possibly with
paste.deploy.loadwsgi.
I'm using ==dev release of pastescript and pastedeploy. I've got a
pair of .ini files much like Laurent, with the only difference between
them being the filter-with and matching [filter:proxy-prefix] section
in the one file.
When I run paster setup-app withprefix.ini I get the same error
message about section 'main' is not the application. When I run the
withoutprefix.ini file, no such problem.
A quick step through getcontext() (using pdb) in loadwsgi.py suggests
to me that something is broken, but I'm lost in the code (new to paste
etc) and know it will take hours to understand enough to track this
down. Roughly speaking, it looks like the code in getcontext() is
returning the filter_with_context instead of the regular app context,
and the caller way up in
paste.script.appinstall.SetupCommand.command() is bothered that the
returned context doesn't have a .distribution attribute and spits out
that error.
That much I can see, but since I don't even know what a context is
here...
On Jul 11, 1:53 pm, Ian Bicking [EMAIL PROTECTED] wrote:
You need to point at the section that has your application
configuration. So if you configuration is in [app:foobar], you have to
change to appconfig('...#foobar') in your test file (in
tests/__init__.py, I think).
I would think the way I'm running it, with paster setup-app, means I'm
not in control of what is being pointed at, but I certainly have an
[app:main] which *is* my application, thus I suspect buggishness.
By the way, this affects only setup-app for me. I can run paster
serve just fine with the withprefix.ini file, so my workaround is to
do paster setup-app withoutprefix.ini, then paster serve
withprefix.ini.
-Peter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: PrefixMiddleware breaks setup-app (was Re: PrefixMiddleware breaks nosetests)
Peter Hansen wrote: I'm encountering the same problem, under slightly different conditions Uh, sorry for the lack of context there (side effect of posting through the web where the other messages are obviously right there in the thread). I was replying to a post by Ian in reply to a thread started by Laurent on July 10, where Laurent showed a problem which gave this error message: File c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste \script\appinstall.py, line 448, in command raise BadCommand( BadCommand: The section 'main' is not the application (probably a filter). You should add #section_name, where section_name is the section that configures your application - I hope that clarifies for anyone who reads the group through email... -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
