Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi-thread environment??? #1

Closed
ghost opened this issue Oct 8, 2014 · 3 comments
Closed

multi-thread environment??? #1

ghost opened this issue Oct 8, 2014 · 3 comments

Comments

@ghost
Copy link

ghost commented Oct 8, 2014

The only thing I found really annoying is the amount of times that PAMAC locks with lock_file since pylamp also has its own lock. I propose to change its blockade by a multi-thread environment where threads lock in the daemon when some client access to danger zones.
This will give you the ease of graphical interface completely separate business, giving greater flexibility to the application.
In a multithreaded enviroment, the thread started by client notifies the thread that is waiting for data (possibly confirmation of a transition).

def EmitTransactionConfirmation(self, info_config):
        self.emit("EmitTransactionConfirmation", info_config)
        self.client_response = False
        self.client_condition.acquire()
        while not self._client_confirm_trans():
            self.client_condition.wait()
        self.client_condition.release()


def Release(self):
        try:
            if not self.client_response:
                self.client_condition.acquire()
                self.client_condition.notify()
                self.client_response = True
                self.client_condition.release()
            self.t.release()
            self.lock_trans.release()
        except:
            pass


def Commit(self):
        if not self.client_response:
            self.client_condition.acquire()
            self.client_condition.notify()
            self.client_response = True
            self.client_condition.release()
        error = ''

 def prepare_transaction_install(self, pkgs, cascade = True, recurse = False):
        self.lock_trans.acquire()
        self.to_add = set()
        self.to_update = set()
        self.to_load = set()
        self.to_remove = set()
@ghost
Copy link
Author

ghost commented Oct 8, 2014

I'm forcing to do that, because i have 3 modules that use the same interface, but i recommend do some thing similar...

@manjaro
Copy link
Collaborator

manjaro commented Oct 11, 2014

Yes, this is a bug we are facing a longer time now. Can you patch pamac to use the proper way and the lock from pyalpm? We will include it right away.

@ghost
Copy link
Author

ghost commented Oct 11, 2014

I currently make this for my application, but in my application only use a subset of pamac... Clear will be more complex for pamac. When i can test that all is working, i will try to add this to pamac, but i think will be better have this in a non master branch for some time, to be tested first... Have dependency of a daemon with multithread, could create several test cases...

@guinux guinux closed this as completed in 0be2ab9 Nov 22, 2014
@pnbalaji pnbalaji mentioned this issue Jul 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants