Hey Dario,
Ok, nice this makes one big new point on my todo list.
So did I understand you right and the problems only occur during a
transaction? That means
all the database-querying stuff works fine without further consideration
in multi-threaded environments?
But the idea of jailing the transaction in a separate process is quite
interesting, but where is the point
in putting alpm in a separate thread? Does this mean, that other
non-transaction stuff also makes
problems in some situations?
Greets
Markus
Dario Freddi wrote:
Hi Markus,
I'm the main developer of Aqpm, a Qt/C++ wrapper of alpm, which is also the
library behind Shaman. Your project seems great, and I hope somebody will use
it to make something just as great!
However, I wanted to let you know that at the moment Alpm behaves strangely in
multithreaded environments. Particularly (I don't know why and I did not
investigate further), when running package scriptlets the operation will stall
completely if more than one thread is active.
You might want to consider this in your library, in Aqpm there's no such
problem as by using PolicyKit, transactions are always jailed in a different
process which is of course single-threaded, and that's probably the only
solution.
I would suggest you to make some tests of pyalpmm in multithreaded
environments, since the highest barrier of alpm in GUI ambits is that it was
not designed with thread usage in mind. Also have a look at Aqpm, which is
completely thread-safe, as I jailed alpm as well in its very own thread, you
might be tempted to adopt a similar solution.
Hope this helped you!
In data sabato 22 agosto 2009 16:45:14, Markus Meissner ha scritto:
: > Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm
You can find more information in this thread (1st post):
http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level
wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos
and aur support ... (like mixing aur and repo packaged in -S)
Several steps are taken towards this goal, like building (mmacman -BI
some_repo_or_aur_pkg) supports both transparently,
searching ( mmacman -Ss query) also supports both: regular repos and
aur. The next step is already the "-S functionality" milestone,
which needs proper AUR pkg dependency resolution - this is in
construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally:
My name is Markus Meissner, living and studying in Germany/Frankfurt -
right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
Greets
Markus
