2009-12-22 2 views
3
([email protected])8> spawn([email protected], tut, test, [hello, 5]). 

Je veux générer un processus sur bar.del.com qui n'a pas accès au système de fichiers à foo.hyd.com (d'où je suis engendrant le processus), en cours d'exécution sous-programme "test" du module "tut".Processus distant Spawn sans système de fichiers commun

Y at-il un moyen de le faire, sans fournir le [email protected] avec le fichier du module "tut" compilé?

+2

12 questions, aucune acceptée ... – jldupont

Répondre

3

Vous pouvez utiliser la fonction suivante pour charger un module au nœud distant sans fournir le fichier lui-même:

load_module(Node, Module) -> 
    {_Module, Bin, Filename} = code:get_object_code(Module), 
    rpc:call(Node, code, load_binary, [Module, Filename, Bin]). 

Comme indiqué dans code:load_binary/3Filename argument est utilisé uniquement pour suivre le chemin d'accès au module et le fichier vers lequel il pointe n'est pas utilisé par local_server_server.

0

Vous pouvez envoyer le code local au noeud distant:

> {Mod, Bin, File} = code:get_object_code(Module). 
> rpc:call(RemoteNode, code, load_binary, [Mod, File, Bin]). 
3

J'interprète votre question comme un désir de ne pas copier les * .beams de votre système de fichiers vers le système de fichiers distant.

Si vous ne faites que tester des choses, vous pouvez utiliser l'appel nl(Mod) dans le shell erl pour charger le module sur tous les nœuds connus (actuellement). Autrement dit, ceux qui apparaissent dans nodes().

Cela va envoyer le code et le charger à partir de la copie de la mémoire, il ne sera pas stocker dans le système de fichiers distant.

Vous pouvez également démarrer le noeud distant à l'aide du module slave. Un esclave accède au système de fichiers et au serveur de code de son maître. Le chargement automatique ordinaire s'assurera alors que le module existe dans l'esclave lorsque vous appelez votre fonction test:tut/2.

+0

hey c'était info utile, je ne savais pas cela. Je vous remercie! – Unoti

Questions connexes