ubuntu-accomplishments-contributors team mailing list archive

[Bruno Girin <brunogirin@xxxxxxxxx>]

On 24/04/12 09:52, Bruno Girin wrote:
> On 24/04/12 06:42, Jono Bacon wrote:
>> Hi Rafal,
>>
>> On 23 April 2012 22:33, Rafał Cieślak <rafalcieslak256@xxxxxxxxx> wrote:
>>> Although I have nothing againist (2) and would consider it as part of
>>> refining the API, I an unsure about the problem involved in (1).
>>>
>>> Considering the case of a just-validated accomplishment I have to
>>> admit that I fail to see why the number of unlocked accomplishments
>>> should anyhow depend on whether the scripts are being run or not.
>>> My point is that, apart from how the dependency checking is
>>> implemented now, in theory it is possible to determine the number of
>>> newly unlocked accomplishments without caring about the state
>>> (running/not). This is not possible using our current implementation,
>>> but I consider it that way: whenever a trophy gets validated, the
>>> daemon should check which accomplishments have just been unlocked by
>>> the fact od that trophy being validated, and report them to the user.
>> Indeed, this was the goal of this email - I also agree that we should
>> be disconnecting the logic of how we check for unlocked
>> accomplishments from the scriptrunner. In my mind the script runner
>> should be pretty simple: it runs scripts and reports the outcome of
>> the script somewhere. Things such as checking for unlocked trophies
>> should be as a result of that resultset from the scripts, not from the
>> scriptrunner itself.
>>
>>> Maybe I am missing something, but I just have a feeling we are doing
>>> something wrong, as unlocking trophies is done in two phases (when
>>> scripts are run and when asc file is got), which will always lead to
>>> race conditions. Shouldn't we do that in one place, and thus avoid
>>> using all there global variables used as hints left by run_scripts?
>> This isn't quite the case - the scriptrunner in run_scripts_for_user()
>> purely runs the scripts and then puts the result of those scripts into
>> self.parent.scriptrun_results, it is later when a trophy arrives and
>> is detected by wait_until_a_sig_file_arrives() that we check if the
>> trophies have been unlocked...the problem is that we check if we
>> should count unlocked trophies today by checking the state of the
>> scriptrunner to ensure it has finished.
>>
>> So, I entirely agree that the current implementation is not serving us
>> well here, I am just unsure what would be the best solution. Any
>> ideas?
> I haven't looked at the implementation for some time so I may be saying
> something stupid here. What I would do is use a producer/consumer
> pattern with a queue of accomplishments to communicate between the
> script runner (consumer) and other parts of the system (producers):
> - the script runner is the consumer: a thread that pops items from the
> head of the queue and runs related scripts; when finished, it checks the
> queue to see if there are more items to process;
> - other parts of the system (e.g. the sig file handling) are producers:
> they push items to the end of the queue, to be consumed by the script
> runner.
>
> By doing this, you would have no need for other parts of the system to
> check if the script runner is running. If required, you could also
> include a threading.Condition object that orchestrates interactions
> between consumers and producers, as explained here:
> http://effbot.org/zone/thread-synchronization.htm#conditions

Actually, there may be an even simpler answer using the queue module:
http://docs.python.org/library/queue.html

Bruno