Date: Fri, 11 Jan 2008 00:35:34 +0200 From: Gunther Mayer <gunther.mayer@googlemail.com> To: freebsd-questions@freebsd.org Subject: Re: Python threading - some ports depend on it, others break with it Message-ID: <47869DB6.20709@gmail.com> In-Reply-To: <80f4f2b20801100731s7ed6b909h774c5ea783c1c664@mail.gmail.com> References: <80f4f2b20801100731s7ed6b909h774c5ea783c1c664@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47869DB6.20709>