if (child_pid > (pid_t) 0)
{
/* Check if it is our child */
if (child_pid == last_child_pid)
Ma question est POURQUOI??
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Les processus sous Linux on comme les Star de Cinéma ?
Passé un certain age il leur sort des fils de tous les cotés ?
Il doit y avoir une réponses car ce qui m'inquiette c'est quand je
fait une rechercher sur des source C qui gère le signal SIGCHID,
Ils utilises Wait pidwait ou wait3 ou wait4 pour récupérer le pid du
défunt fils, mais ils testent tous que ce pid soit bien le fils ??
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort
de mon fils, et pas d'un cousin ou voisin alors ???
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent Wacrenier
écrit:
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils. C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état, le fils a pu être suspendu ou continuer après une suspension. Il y a des options pour contrôler celà.
ProjLIN@hotmail.com <projlin@hotmail.com> écrit:
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils.
C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état,
le fils a pu être suspendu ou continuer après une suspension.
Il y a des options pour contrôler celà.
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils. C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état, le fils a pu être suspendu ou continuer après une suspension. Il y a des options pour contrôler celà.
Anthony Fleury
wrote:
Bonjour,
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet ou ici dans le traitement du signal On trouve quasiment toujours un test du genre child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0) { /* Check if it is our child */ if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier argument est équivalent en comportement à wait en fait. De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD, c'est plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et si l'on doit revenir sur des millions de lignes de codes pour ajouter un processus dans un module, ca le fait moyennement...
</HS>
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
ProjLIN@hotmail.com wrote:
Bonjour,
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur
un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet
ou ici dans le traitement du signal
On trouve quasiment toujours un test du genre
child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0)
{
/* Check if it is our child */
if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en
premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si
c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il
faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier
argument est équivalent en comportement à wait en fait.
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne
veulent pas mettre les pid dans waitpid car si un jour le programme se
forke un autre coup il faudra revenir changer ca pour éviter les
comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD, c'est
plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort
de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour
mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et
si l'on doit revenir sur des millions de lignes de codes pour ajouter un
processus dans un module, ca le fait moyennement...
</HS>
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet ou ici dans le traitement du signal On trouve quasiment toujours un test du genre child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0) { /* Check if it is our child */ if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier argument est équivalent en comportement à wait en fait. De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD, c'est plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et si l'on doit revenir sur des millions de lignes de codes pour ajouter un processus dans un module, ca le fait moyennement...
</HS>
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
projlin
ok oui suis-je étourdis je vois bien cela
genre je fait dans mon programme plus loin un appel a une fonction qui en douce fait un fils pour le faire bosser quand ce fils moeurs je reçois un SIGCHILD d'un fils que je ne connais pas...
ok ok je comprends mieux...
merci, car je n'avais pas penser a cela, mais tous les sources que je voyais sur internet, faisais un test comme si on pouvais avoir pleins de fils alors que c'étais pour la gestion d'un fils unique...
merci pour éclairage .... ;-)
"Laurent Wacrenier" <lwa@ teaser . fr> a écrit dans le message de news:
écrit:
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils. C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état, le fils a pu être suspendu ou continuer après une suspension. Il y a des options pour contrôler celà.
ok oui suis-je étourdis je vois bien cela
genre je fait dans mon programme plus loin un appel a une fonction qui en
douce fait un fils pour le faire bosser
quand ce fils moeurs je reçois un SIGCHILD d'un fils que je ne connais
pas...
ok ok je comprends mieux...
merci, car je n'avais pas penser a cela, mais tous les sources que je voyais
sur internet,
faisais un test comme si on pouvais avoir pleins de fils alors que c'étais
pour la gestion d'un fils unique...
merci pour éclairage .... ;-)
"Laurent Wacrenier" <lwa@ teaser . fr> a écrit dans le message de news:
slrnc8ajf7.2clr.lwa@victor.teaser.fr...
ProjLIN@hotmail.com <projlin@hotmail.com> écrit:
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils.
C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état,
le fils a pu être suspendu ou continuer après une suspension.
Il y a des options pour contrôler celà.
genre je fait dans mon programme plus loin un appel a une fonction qui en douce fait un fils pour le faire bosser quand ce fils moeurs je reçois un SIGCHILD d'un fils que je ne connais pas...
ok ok je comprends mieux...
merci, car je n'avais pas penser a cela, mais tous les sources que je voyais sur internet, faisais un test comme si on pouvais avoir pleins de fils alors que c'étais pour la gestion d'un fils unique...
merci pour éclairage .... ;-)
"Laurent Wacrenier" <lwa@ teaser . fr> a écrit dans le message de news:
écrit:
Pour quoi faire un "test de paternité" sur le signal sigchid ??
Peut être parce que une librairie a pu lancer sauvagement des fils. C'est plutôt un bug de la librairie.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
Pas nessessairement, SIGCHLD est envoyé lors d'un changement d'état, le fils a pu être suspendu ou continuer après une suspension. Il y a des options pour contrôler celà.
projlin
hello, et merci pour le coup de main
waitpid avec -1 en premier argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la possibilité de ne pas etre bloquant grace a WNOHANG, alors que le wait il est forcément bloquant ...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
merci
"Anthony Fleury" a écrit dans le message de news: 40855179$0$22863$
wrote:
Bonjour,
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet ou ici dans le traitement du signal On trouve quasiment toujours un test du genre. child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0) { /* Check if it is our child */ if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier argument est équivalent en comportement à wait en fait. De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD, c'est
plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et si l'on doit revenir sur des millions de lignes de codes pour ajouter un processus dans un module, ca le fait moyennement...
</HS>
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
hello, et merci pour le coup de main
waitpid avec -1 en premier
argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la
possibilité de ne pas etre bloquant grace
a WNOHANG, alors que le wait il est forcément bloquant ...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne
veulent pas mettre les pid dans waitpid car si un jour le programme se
forke un autre coup il faudra revenir changer ca pour éviter les
comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
merci
"Anthony Fleury" <fleury_anthony@hotmail_.com> a écrit dans le message de
news: 40855179$0$22863$626a14ce@news.free.fr...
ProjLIN@hotmail.com wrote:
Bonjour,
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur
un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet
ou ici dans le traitement du signal
On trouve quasiment toujours un test du genre.
child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0)
{
/* Check if it is our child */
if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en
premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si
c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il
faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier
argument est équivalent en comportement à wait en fait.
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne
veulent pas mettre les pid dans waitpid car si un jour le programme se
forke un autre coup il faudra revenir changer ca pour éviter les
comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD,
c'est
plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort
de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour
mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et
si l'on doit revenir sur des millions de lignes de codes pour ajouter un
processus dans un module, ca le fait moyennement...
</HS>
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
waitpid avec -1 en premier argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la possibilité de ne pas etre bloquant grace a WNOHANG, alors que le wait il est forcément bloquant ...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
merci
"Anthony Fleury" a écrit dans le message de news: 40855179$0$22863$
wrote:
Bonjour,
Bonjour, à noter que cette question est HS ici, elle a plutot sa place sur un forum unix.
[...]
<HS>
Dans quasiment toutes les routines en C que l'on trouve sur Internet ou ici dans le traitement du signal On trouve quasiment toujours un test du genre. child_pid = waitpid ((pid_t) -1, &child_status, WNOHANG);
if (child_pid > (pid_t) 0) { /* Check if it is our child */ if (child_pid == last_child_pid)
Ma question est POURQUOI??
ca dépend du programme, est-ce sûr qu'il n'a qu'un fils ? en fait le -1 en premier paramètre veut dire attente d'un sigchild pour *l'un* des fils. Si c'est >0, c'est donc le pid d'un des fils qui est dans child_pid, mais il faut quand même savoir si c'est celui attendu. waitpid avec -1 en premier argument est équivalent en comportement à wait en fait. De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
Si je reçois un signal sigchild c'est que mon fils est mort non ????
attention, dans le cas d'un SIGSTOP le père recoit aussi un SIGCHILD, c'est
plutot un "changement d'état" d'un processus fils
Pourtant mes lecture sur le signal disent que SIGCHILD c'est la mort de mon fils, et pas d'un cousin ou voisin alors ???
encore une fois de _l'un_ des fils, dans un ptit projet que j'ai fait pour mon école j'en suis déjà à 6, ca se reproduit vite les processus unix. Et si l'on doit revenir sur des millions de lignes de codes pour ajouter un processus dans un module, ca le fait moyennement...
</HS>
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Anthony Fleury
projlin wrote:
hello, et merci pour le coup de main
Hello,
Tout ceci est encore HS bien sûr
waitpid avec -1 en premier argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la possibilité de ne pas etre bloquant grace a WNOHANG, alors que le wait il est forcément bloquant ...
Oui bien sûr, mais je parlais en terme de réceptions de signaux, il recoit dans ce cas les signaux de tous les fils. Enfin en effet petit manque de précision de ma part...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
Prenons l'exemple d'un programme avec 1 processus père et un fils. Il y a deux solutions avec waitpid() pour attendre la fin d'un fils :
waitpid(pidfils, ...); waitpid(-1, ...);
Premier cas, on attend la mort d'un fils précis, on peut alors agir en conséquence, si le résultat de waitpid() est supérieur à 0, sachant que le fils a bien changé d'état. Second cas, c'est un processus fils qui s'est terminé. Même résultat dans le cas >0, on sait que l'état du fils a bien changé. Comme il n'y a qu'un fils, on sait assurément que c'est le bon fils. Maintenant dans le cas de la seconde solution, si jamais on ajoute un autre processus, et que celui ci meurt , le père va recevoir un SIGCHILD encore, mais pas du bon, il va donc avoir un mauvais comportement car il ne saura pas la vérité, le bon fils ne sera pas mort. En fait je pensais surtout à des problèmes de synchronisation ; dans ce cas on agit en conséquence selon le fils qui est mort...
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
projlin wrote:
hello, et merci pour le coup de main
Hello,
Tout ceci est encore HS bien sûr
waitpid avec -1 en premier
argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la
possibilité de ne pas etre bloquant grace
a WNOHANG, alors que le wait il est forcément bloquant ...
Oui bien sûr, mais je parlais en terme de réceptions de signaux, il recoit
dans ce cas les signaux de tous les fils. Enfin en effet petit manque de
précision de ma part...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne
veulent pas mettre les pid dans waitpid car si un jour le programme se
forke un autre coup il faudra revenir changer ca pour éviter les
comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
Prenons l'exemple d'un programme avec 1 processus père et un fils. Il y a
deux solutions avec waitpid() pour attendre la fin d'un fils :
waitpid(pidfils, ...);
waitpid(-1, ...);
Premier cas, on attend la mort d'un fils précis, on peut alors agir en
conséquence, si le résultat de waitpid() est supérieur à 0, sachant que le
fils a bien changé d'état.
Second cas, c'est un processus fils qui s'est terminé. Même résultat dans le
cas >0, on sait que l'état du fils a bien changé. Comme il n'y a qu'un
fils, on sait assurément que c'est le bon fils. Maintenant dans le cas de
la seconde solution, si jamais on ajoute un autre processus, et que celui
ci meurt , le père va recevoir un SIGCHILD encore, mais pas du bon, il va
donc avoir un mauvais comportement car il ne saura pas la vérité, le bon
fils ne sera pas mort. En fait je pensais surtout à des problèmes de
synchronisation ; dans ce cas on agit en conséquence selon le fils qui est
mort...
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
waitpid avec -1 en premier argument est équivalent en comportement à wait en fait.
heuu non en fait waitpid -1 a le meme comportement que wait mais il a la possibilité de ne pas etre bloquant grace a WNOHANG, alors que le wait il est forcément bloquant ...
Oui bien sûr, mais je parlais en terme de réceptions de signaux, il recoit dans ce cas les signaux de tous les fils. Enfin en effet petit manque de précision de ma part...
De plus c'est quand même une bonne habitude à prendre pour ceux qui ne veulent pas mettre les pid dans waitpid car si un jour le programme se forke un autre coup il faudra revenir changer ca pour éviter les comportements étranges.
c'est a dire ? précise ?? pouquoi il faut changer cela dans ce cas ??
Prenons l'exemple d'un programme avec 1 processus père et un fils. Il y a deux solutions avec waitpid() pour attendre la fin d'un fils :
waitpid(pidfils, ...); waitpid(-1, ...);
Premier cas, on attend la mort d'un fils précis, on peut alors agir en conséquence, si le résultat de waitpid() est supérieur à 0, sachant que le fils a bien changé d'état. Second cas, c'est un processus fils qui s'est terminé. Même résultat dans le cas >0, on sait que l'état du fils a bien changé. Comme il n'y a qu'un fils, on sait assurément que c'est le bon fils. Maintenant dans le cas de la seconde solution, si jamais on ajoute un autre processus, et que celui ci meurt , le père va recevoir un SIGCHILD encore, mais pas du bon, il va donc avoir un mauvais comportement car il ne saura pas la vérité, le bon fils ne sera pas mort. En fait je pensais surtout à des problèmes de synchronisation ; dans ce cas on agit en conséquence selon le fils qui est mort...
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
