RE: Python threading - some ports depend on it, others break with it
I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support. However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things. ... I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken? I would suggest framing either some of the programs/libraries with a few counts of 1st degree murder, and sending it to jail for life, where it can run for life in a nice little cell with it's own pet python. Would that work? It's probably a bit more work than a desirable solution, but if you don't need them running in the same space, it should work. Or have I completely missed the point (very likely given me). -Jim Stapleton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Python threading - some ports depend on it, others break with it
Jim Stapleton wrote: I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support. However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things. ... I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken? I would suggest framing either some of the programs/libraries with a few counts of 1st degree murder, and sending it to jail for life, where it can run for life in a nice little cell with it's own pet python. Would that work? It's probably a bit more work than a desirable solution, but if you don't need them running in the same space, it should work. Or have I completely missed the point (very likely given me). It's a good suggestion but I can see that being more trouble than it's worth. I wouldn't want to spend countless hours making sure that all those files, their dependencies, libraries and all that other jazz is in a jail on its own working smoothly, and even if I get it right upgrading components (e.g. security vulnerabilities) will prove to be a nightmare. Getting a second box is out of the question, for now at least, and while I thought virtualization might be the answer I see that FreeBSD only has guest support for Xen :-( Oh well, guess I'll post to freebsd-python to get some solution perhaps. Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Python threading - some ports depend on it, others break with it
On Wednesday 09 January 2008 19:40:04 Gunther Mayer wrote: Hi guys, I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support. However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things. Chicken and egg - one of my ports insists on python with threads enabled, the other port insists I use python without thread support. My workaround is to compile python without threading, install(or upgrade) postgresql-plpython, then recompile python with threading, install(or upgrade) trac and pray that plpython won't eat my dog when I use it. A really painful and error prone exercise, especially when an upgrade comes along (security or otherwise). I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken? To get you an idea of what versions I'm running, the affected postgresql ports are postgresql-plpython-8.2.6 postgresql-server-8.2.6 for the trac dependencies the involved culprits are: py25-pysqlite-2.0.7_1 python25-2.5.1_1 python-2.5,2 sqlite-3.3.8 # peripheral I remember with python 2.4 I had the same endless issues over a year ago so it's not 2.5's fault. Oh, and btw, I'm running 6.2-RELEASE-p9 i386. Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] It's my understanding that threading *in* python works well, but threading *with* python doesn't and you shouldn't use/rely on it. I'm afraid I can't tell you much more without an hour of googling and I wouldn't be sure if I can adequately explain after. I think it has to do with the GIL. I suggest to ask at [EMAIL PROTECTED] Dan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Python threading - some ports depend on it, others break with it
On 10/01/08 Danny Pansters said: It's my understanding that threading *in* python works well, but threading *with* python doesn't and you shouldn't use/rely on it. I'm afraid I can't tell you much more without an hour of googling and I wouldn't be sure if I can adequately explain after. I think it has to do with the GIL. I suggest to ask at [EMAIL PROTECTED] Threading in Python works fine in my experience, even using native threads. It is not very efficient on multi-core systems though, due to the GIL (global interpreter lock). Mike -- Michael P. Soulier [EMAIL PROTECTED] Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein signature.asc Description: Digital signature
