Discussion :

[adiGuba]

Le problème se posera à la prochaine jdk ... si suppression y a ...

Ou même avant : cela peut provoquer des erreurs innatendus dans tes autres threads...

a++

[mlle lain]

Nonon c'est le seul.
Merci d'avoir passé du temps à m'aider.

[®om]

Nonon c'est le seul.
Merci d'avoir passé du temps à m'aider.

Ca ne peut pas être le seul, sinon tu n'aurais pas eu besoin d'en créer un

Tu en as déjà 3 quand tu lances un programme : EDT pr gérer le graphisme, le truc qui gère le GC, et le thread de ton appli... Donc + celui là ça fait 4

[adiGuba]

Nonon c'est le seul.
Merci d'avoir passé du temps à m'aider.

Si c'est le seul cela signifie que tu es en mono-thread et donc que tu arrêtes ton application...

a++

[mlle lain]

Pinaillez donc pas les gars : C'est le seul que je crée moi même à la menotte.
En tout cas, java pour les appli critiques c'est pas top : ne plus avoir un "emergency stop" pour des threads sensibles c'est renversant

[Betatesteur]

Pinaillez donc pas les gars : C'est le seul que je crée moi même à la menotte.
En tout cas, java pour les appli critiques c'est pas top : ne plus avoir un "emergency stop" pour des threads sensibles c'est renversant

c'est un terrain que tu ne maitrises pas.
Je te pardonne de ce que tu viens de dire

[mlle lain]

Tu as raison de m'expliquer au moins je risque de finir par comprendre

[professeur shadoko]

En tout cas, java pour les appli critiques c'est pas top : ne plus avoir un "emergency stop" pour des threads sensibles c'est renversant

il y a là un oxymore: "application critique" ET "emergency stop".
Si c'est critique c'est que ça fait des choses importantes ... si tu flingues "de l'extérieur" ces choses importantes risquent de ne pas être terminées ou de se retrouver dans un état que la morale réprouve.
Donc c'est fromage OU dessert: ou tu flingues, ou c'est critique mais pas les deux.
Bon je joue un peu sur les mots mais c'est pour faire comprendre le pourquoi: quand tu utilises le bouton "urgence" tu fais des choses graves ... mais bon si tu penses que l'urgence t'autorise à avoir un pourcentage de pertes c'est une décision qui t'appartient (c'est juste pour souligner qu'il est difficile de juger des absolus : en règle générale Java considère que c'est pas bon de débrancher le courant, mais si tu juges que ça ne s'applique pas à ton cas, tu es dans un cas particulier -peut-être tout à fait valide, mais un cas particulier quand même-)

[mlle lain]

On joue sur les mots effectivement mais je pense grave pas être un cas particulier
Le process qui est lancé peut prendre des heures. Oui, des heures, à mouliner gentiment. Si mon utilisateur s'aperçoit au bout de deux minutes que "Ah merde c'est pas 5.0 mais 5.5 que je voulais mettre en valeur du 44ème paramètres" je voudrais lui éviter de faire un beau ctrl + alt + supp pour killer l'appli (ce qu'il fait actuellement, question sureté je crois qu'on peut voir mieux )
J'ai pas accés aux sources pour rajouter des flags ou quoi que ce soit.
Je ne peut qu'instancier la classe qui fait le traitement.
C'est tout.
Je comprends tout ce que vous me dites, y a pas de soucis. Mais "l'emergency stop" est quand même le truc qu'on met en premier en place sur pas mal de système. A charge derrière d'assurer le suivie propre d'un arrêt d'urgence.

Merci à tous pour votre aide

[BainE]

ben, si tu craint pas de laisser des flux ouverts, des process zombies..., peut etre qu'une surcharge de la méthode "finalize()" en essayant de cloturer au plus propre les actions possibles en cours pourrait limiter les etats aléatoires
C'est juste une idée... soumis à vos avis experts

[manblaizo]

Bonjour,
Moi il y a quelque chose qui m'interpelle. Si la méthode appelée peut être blocante pour des heures, alors le concepteur de cette API doit sûrement en être conscient et a dû prévoir un moyen pour arrêter le thread courant, un peu à l'image de l'API "java.nio" ou "java.net" (genre, lever une exception après un appel à la méthode Thread.interrupt()). En tout cas, comme cela a été bien expliqué plus haut, il ne serait pas sain d'arrêter brutalement un thread de l'extérieur. Une possibilité serait de réécrire la méthode qui pose problème, au cas où tu aurais accès au code, pour tenir compte du besoin de mettre fin aux threads.