Coexistence Preamptif Coopératif?

Bonjour

Je viens de lire la doc et ce n’est pas très clair.

Est-ce qu’un process preemptif peut appeler un worker coopératif ?

Je voudrais mettre mon serveur web en mode préemptif mais j’ai des fonctionnalités qui impriment des documents (Imprimer ligne, saut de page…), est-ce que mon process web thread-safe pourra appeler un worker coopératif qui s’en occupera ?

Sinon je suis dans la ***, ça serait dommage de passer à côté du préemptif pour 3 bricoles… sinon je vais devoir faire communiquer 2 bases pour mixer :slight_smile:

La doc dit rien la dessus.

Merci d’avance pour vos solutions :slight_smile:

Salut

Tu peux très bien générer un worker pour faire cela en passant les infos en paramètre, mais ce sera alors exécuté de manière asynchrone.

Effectivement, comme j’avais pas la patience d’attendre une réponse, j’ai créé une petite base pour le tester et ça fonctionne :slight_smile: on peut imprimer un PDF à partir d’un process web pré-emptif :slight_smile:

En fait, je vais créer un worker “Utilitaires” qui fera tout ce qui est coopératif, c’est plutôt pratique je pense car c’est pas plus mal que les traitements se fassent à la queue-leu-leu plutôt qu’en parallèle en coopératif.

Bon j’ai encore du boulot… 5800 erreurs pour l’instant du genre la méthode est pas thread-safe…

J’essayerais QS_Toolbox dès que j’en aurais marre de tester mes erreurs.

Merci :slight_smile:

Vous avez un worker “utilitaire” à disposition dans 4D c’est le process principal :wink:

CALL WORKER (1;…)
1 Like

Ah, bonne idée, ça a un intérêt par rapport à un worker créé ?

Un worker n’est jamais qu’un nouveau process avec des caractéristiques différentes

Note que VDL a mis un smiley. Bien que le process principal soit un worker il est un peu spécial

Faut croire que oui, je pense pas que Vincent te tende un piège, avril est fini :wink:

Je suppose que pour faire de petits traitements de ci de là, comme il n’a pas grand chose à faire, il doit pouvoir tenir lieu de petite main ; c’est plus simple que lancer un worker “petiteMain”, de conserver sa référence pour l’appeler quand on a du boulot pour lui : là, c’est le 1, je pense arriver à m’en rappeler.

Exclure toute interface, par contre, je pense : j’avais essayé de lancer un DIALOGUE, les événements formulaire ne marchent pas du tout comme on s’y attend, ça n’a pas l’air fait pour ça.

un exemple :

J’ai une méthode CALL_MAIN_PROCESS pour effectuer quelques tâches qui ne sont pas possible en préamptif.

l’appel :

$signal:=New signal("CALL_MAIN_PROCESS")
CALL WORKER(1;"CALL_MAIN_PROCESS";$signal;"listOfLoadedComponents")
If ($signal.wait(1))
  $o.success:=($signal.value.indexOf("4D SVG")#-1)
  If ($o.success)
    EXECUTE METHOD("SVGTool_SHOW_IN_VIEWER";*;$o.root)
  Else 
    $o.errors.push("The component \"4D SVG\" is not avaiable.")
  End if 
End if 

la méthode CALL_MAIN_PROCESS :

$signal:=$1

Case of 
	: ($2="listOfLoadedComponents")
		
		ARRAY TEXT($aT;0x0000)
		COMPONENT LIST($aT)
		
		Use ($signal)
			
			$c:=New shared collection
			ARRAY TO COLLECTION($c;$aT)
			$signal.value:=$c
			
		End use 
	
…

End case 

$signal.trigger()

In my experience, it is also necessary to protect the signal code, because the signal could disappear during the wait.

e.g.

If (Not(Process aborted))
	
	$signal.trigger()
		
End if
2 Likes