[pacman-dev] Little hello and pyalpmm announcement

Dario Freddi drf54321 at gmail.com
Sun Aug 23 14:43:46 EDT 2009


Hi Markus,

In data domenica 23 agosto 2009 19:45:48, Markus Meissner ha scritto:
: > 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?

Yes, given that you control race conditions. Every function is not thread-
safe.

>
> 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?

No, it does not; I just wanted to make sure that Aqpm was completely thread-
safe, since with the old Shaman I had a problem with some race conditions 
making it crash on multiple queries. This point really depends on what is your 
final target: if you plan to develop a full-fledged frontend à-la-Shaman, my 
advice is to go for thread-safety.

Python probably won't suffer from some problems I run into (and I wrote Shaman 
when I was much less capable of coding and less experienced, and you can tell 
it :) ), but the best way (to me) is to see first how pyalpmm reacts in 
multithreaded environments by making some unit tests, and then decide. This 
would save your time and prevent eventual future problems.

>
> 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

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://www.archlinux.org/pipermail/pacman-dev/attachments/20090823/c02d67fc/attachment-0001.pgp>


More information about the pacman-dev mailing list