2013/4/26 Matěj Laitl <ma...@laitl.cz>: >> While such a daemon will probably not be ready in time for GSOC creating the >> Backend in such a way that adding support for synchronous or preferably >> asynchronous DBus access would be a very good thing. > > I absolutely agree. Even before I knew about this, the plan was to have *all* > LIBMTP_*() calls (or rather groups with a handful of libmtp calls) wrapped in > ThreadWeaver::Jobs, for technical reasons (some libmtp calls may block for > some time -> need to have them threaded -> libmtp doesn't say anything about > thread-safety AFAICS -> need to serialize access to it (per device) -> all > libmtp calls may then block on lock acquisition -> all libmtp calls must be > threaded).
libmtp has per-device reentrance, so you can make calls to several devices as a state struct is instatiated per-device, and the rest of the code should be stateless. If it isn't then it's a bug... I've tried to hold off patches that does not respect this. Yours, Linus Walleij _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
