Re: Re: MathLink portnumbers and internal types
- To: mathgroup@smc.vnet.net
- Subject: [mg10986] Re: [mg10981] Re: [mg10937] MathLink portnumbers and internal types
- From: jpk@max.mpae.gwdg.de
- Date: Mon, 16 Feb 1998 03:39:54 -0500
Hi John, I had verrry bad experiences with the MLName() function. I have a implementation of an parallel Runge-Kutta method the program (dirkml) is called from Mathematica and calls it self a second time the communication is MathKernel <-> dirkml (P1) <-> dirkml (P2) during the integration of one set of ode's P1 and P2 communicate verry intensive. The program may run as P1 process or as P2 process due to a command line switch (+p2run) and work as slave to P1 or as MathLink child for Mathematica. For the speed testing I asked the support about the default protokol for every communication. A question to the Mathematica support reports several (undocumented) functions including MLName(). I strongly recommend to avoid MLName(). because - I tryed it on two Ultra SPARC computers. You can not call MLName() before the connection is established from both sides! If dirkml (as P1) calls dirkml (as P2) MLName() yields somthing like "/export/home/DIRK/dirkml" (no port number or any usefull information) When dirkml (as P2) has created the connection MLName() gives portnumber@host. But that is probably to late to use the information for a peer to peer connection. - I try the same program on my Linux box at home and it crashes with a core dump until I remove the entire MLName() call. - needless to say that I got nothing to work on a MS-Windows machine My peer to peer connection between Mathematica, dirkml (P1) and dirkml (p2) is setup as follows. As long as dirkml (as P1) and dirkml (as P2) run on the same machine all works automatic with MLOpen(). On different machines I first start dirkml (as P2) jpk@host2> ./dirkml +p2run -linkcreate this causes dirkml to run as P2, to create a link and wait until P1 is running. I writes out the correct linkname say 12345@host2. Than on the second machine I start jpk@host1> ./dirkml +p2connect -p2lname 12345@host2 -linkcreate That tells P1 that a P2 process is waiting (+p2connect) and the link is 12345@host2. P1 connects to P2 and creates a new link (say 54321@host1) that can be used by Mathematica's Install[LinkConnect["54321@host2"]] to establish the connection between P1 and Mathematica's kernel. This works fine on my SPARC's as well on the Linux boxes. The problem is how to pass the information "P2 is waiting for You" to P1. An other possibility may be to let P2 write the information on a file that is shared over nfs between the two machines. You can have the source code as well as the sample notebooks for the timing tests. But until the article about the parallel Runge-Kutta method is not published I can't put the full information on MathSource or post it into the news group. Best regards Jens > It would be bad to expose MLINK and MLENV to user tinkering. > Implementational details of data types such as these are hidden to make > it easier to keep MathLink source code compatible from one revision of > Mathematica to the next. If programmers rely on internal knowledge of > these structures, then the compatibility issue becomes a very difficult > one. Much the similar philosophy is taken in many other API's; for > example, the Win32 API similarly hides implementational details for > handles to windows, device contexts, fonts, brushes, etc. > > The correct thing to do is to have an API whereby you can query the > attributes of an MLINK or MLENV as required. There is, in fact, an API > that queries the information you need from an MLINK pointer; if you > look in mathlink.h, you'll see the following: > > /* MLName returns a pointer to the link's name. > * Links are generally named when they are created > * and are based on information that is potentially > * useful and is available at that time. > * Do not attempt to deallocate the name's storage > * through this pointer. The storage should be > * considered in read-only memory. > */ > MLDECL( kcharp_ct, MLName, ( MLINK mlp)); MLDECL( long, > MLNumber, ( MLINK mlp)); MLDECL( charp_ct, MLSetName, ( MLINK mlp, > kcharp_ct name)); > > So, MLName returns a const char * pointer to the linkname (i.e. > "####@host" for a TCP connection). I think (but don't recall for > certain) that MLNumber returns the actual socket number (for a TCP > connection) from that. > > Incidentally, I agree that you shouldn't have to go mucking about in > mathlink.h to try to get this information; unfortunately, I don't know > of anywhere else where this particular information is documented. > > > I will be very grateful for any pointers! > > > > -- > > /Stefan > > f94stbe@dd.chalmers.se > > Sincerely, > > John Fultz > jfultz@wolfram.com > Front End Group > Wolfram Research, Inc. >