Hi Marc, On 21/06/11 16:50, Marc - A. Dahlhaus wrote: > We simply remove the JobClass of the removed config form the alias list > inside of the known_job and if ->job and ->alias are empty after that > we remove the entire entry from known_jobs in that case... Having re-read your mail here, I think I have been "thinking at crossed purposes" here - I was fixating somewhat on JobAlias rather than NamedJob.
I see what you are saying now. This is a good idea, although we would still be storing job *names* in 2 locations (maybe not such a big deal): in JobClass->name in job_classes and also in NamedJob->name. Nominally, the NamedJob struct would also disallow aliases with the same names as a job (assuming nih_hash_string_new()). This is probably the behaviour we want anyway though. > We don't have to change that. As the ->job member above is exactly that. > We have an array behind ->aliases that would be filled with jobs that > provide a given alias. We just need to extend the lookup-logic for that > list that is used by the signals initctl sends to check which job should > handle the signal. Right. I'll try and grab you on irc this week or next so we can discuss this further. Speak soon. Kind regards, James Hunt ____________________________________ http://upstart.ubuntu.com/cookbook http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
