| | 55 | |
| | 56 | |
| | 57 | == Cas asynchrone - avec post-traitement == |
| | 58 | |
| | 59 | Il y a de nombreux cas ou le script de soumission doit reprendre la main après l'exécution du code de calcul. |
| | 60 | Cependant, il faut savoir que le shell ne gère les signaux qu'entre deux instructions, |
| | 61 | ou lors d'instruction bloquante interne au shell (par exemple {{{wait}}}). |
| | 62 | |
| | 63 | L'exemple suivant par exemple ne fonctionne pas |
| | 64 | car le script exécutera le code dans {{{trap}}} qu'une fois le code {{{mycode}}} finit, |
| | 65 | donc en pratique jamais car le code dure plus de 24h. |
| | 66 | Au final, au bout de 24, {{{OAR}}} fera un {{{kill}}} violent du code... |
| | 67 | {{{ |
| | 68 | #!/bin/bash |
| | 69 | |
| | 70 | #OAR -n MYCODE |
| | 71 | #OAR -t idempotent |
| | 72 | #OAR --checkpoint 600 |
| | 73 | #OAR -l /core=1,walltime=24:00:00 |
| | 74 | |
| | 75 | # Signal child retransmit |
| | 76 | trap 'kill -USR2 $(jobs -p)' USR2 |
| | 77 | |
| | 78 | |
| | 79 | # Load environment |
| | 80 | . /etc/profile |
| | 81 | |
| | 82 | module load intel/2011.7 |
| | 83 | |
| | 84 | |
| | 85 | # Pretreatment possible here |
| | 86 | |
| | 87 | |
| | 88 | # Start / give the hand to the code |
| | 89 | ./mycode |
| | 90 | |
| | 91 | |
| | 92 | # Post-treatment possible here |
| | 93 | |
| | 94 | }}} |
| | 95 | |
| | 96 | Une solution est de lancer le code en asynchrone |
| | 97 | afin que le script de soumission reprenne le plus vite possible la main. |
| | 98 | Cependant, il doit quand même attendre la fin du code avant de faire l'étape de post-traitement. |
| | 99 | Voici une solution fonctionnelle à ces impératifs |
| | 100 | |
| | 101 | {{{ |
| | 102 | #!/bin/bash |
| | 103 | |
| | 104 | #OAR -n MYCODE |
| | 105 | #OAR -t idempotent |
| | 106 | #OAR --checkpoint 600 |
| | 107 | #OAR -l /core=1,walltime=24:00:00 |
| | 108 | |
| | 109 | # Signal child retransmit |
| | 110 | trap 'kill -USR2 $(jobs -p)' USR2 |
| | 111 | |
| | 112 | |
| | 113 | # Load environment |
| | 114 | . /etc/profile |
| | 115 | |
| | 116 | module load intel/2011.7 |
| | 117 | |
| | 118 | |
| | 119 | # Pretreatment possible here |
| | 120 | |
| | 121 | |
| | 122 | # Launch the code and take back the hand (asynchrone) |
| | 123 | ./mycode & |
| | 124 | |
| | 125 | # Wait for the end of the code |
| | 126 | while [ $(jobs -p | wc -l) -gt 0 ] |
| | 127 | do |
| | 128 | wait |
| | 129 | done |
| | 130 | |
| | 131 | # Post-treatment possible here |
| | 132 | |
| | 133 | }}} |
| | 134 | |
| | 135 | La boucle while est très importante |
| | 136 | car le code peux finir suite à la réception d'un signal |
| | 137 | mais aussi naturellement lorsqu'il a enfin finit son traitement global. |
| | 138 | Les deux cas doivent être géré. |
| | 139 | Or la commande interne '''{{{wait}}}''' attends la '''fin du calcul''' |
| | 140 | ou la '''réception d'un signal'''. |
| | 141 | |
| | 142 | Une fois le signal reçu, la commande {{{trap}}} retransmet le signal au code, |
| | 143 | et le script de soumission repars dans la boucle {{{while}}} |
| | 144 | afin d'attendre la fin réelle du code. |
| | 145 | Sans cette boucle, |
| | 146 | il passerait de suite sur la phase de post-traitement |
| | 147 | et se terminerait en laissant {{{OAR}}} tuer sauvagement le code dans sa phase terminale... |