ubuntu-accomplishments-contributors team mailing list archive

[Bruno Girin <brunogirin@xxxxxxxxx>]

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

Bruno