Louise-Amélie Schmitt wrote:
Le 02/06/2011 21:39, Nate Coraor a écrit :
>Louise-Amélie Schmitt wrote:
>>>default_cluster_job_runner will remain for backwards compatibility, but
>>>we'll ship a sample job_conf.xml that runs everything locally by
>>>default.
>>>
>>>--nate
>>Haha, and I did that before realizing I could do just what I needed by
>>writing tool-specific pbs:// URLs at the end of the config file... I'm such
>>an idiot.
>Haha, okay, I don't think i even noticed since I was distracted by your
>implementation being a step in the way we want to go with it.
>
damn, I shouldn't have said anything :D
>>But I really like what you did of it and I have a couple of questions.
>>
>>Concerning the single-threaded tools, what would happen if the number of
>>threads set in the xml file was>1 ?
>It'd consume extra slots, but the tool itself would just run as usual.
>
So what about an attribute in the tool tag that would notify wether
the tool is actually multithreaded, so that this doesn't happen?
Something like multithreaded="true/false" ?
I'm not sure if it's something we need to enforce (who knows, maybe I
have some reason for having a single-threaded tool reserve multiple
slots), but I do think there should be some way for tool authors to make
it known that their tool is multithreaded.
--nate
>>Could it be possible to forbid a tool to run on a given
node?
>Hrm. In PBS you could do it using node properties/neednodes or resource
>requirements. I'd have to think a bit about how to do this in a more
>general way in the XML.
>
>--nate
>
Ok thank you! :)
L-A
>>Thanks,
>>L-A
>>
>>
>>>>Peter
>>>>