Re: Re: MathLink portnumbers and internal types
- To: mathgroup@smc.vnet.net
- Subject: [mg11004] Re: [mg10981] Re: [mg10937] MathLink portnumbers and internal types
- From: John Fultz <jfultz@wolfram.com>
- Date: Mon, 16 Feb 1998 18:15:13 -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. It's not clear to me exactly what method you used to create this link. While I can't authoritatively say without more study what MLName() returns in all cases (maybe, for example, it does return the program name for linkmode launch...I'm not sure right now), I can say that, in my experience, it most definitely returns a socket number if you create a listening link on a TCP protocol. > - 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 I have some difficulty believing that MLName() is, in general, broken. MLName() is used in the code generated by mprep (it's how installable MathLink programs know what name to print when you do "addtwo -linkcreate"), and it is also used by the front end for launching remote kernels to connect using the TCP protocol. Any generic problems in MLName() should cause problems in these two facilities, as well. I've not seen any such problems, although I admit to never having tried any MathLink stuff on an UltraSPARC. Without more information, the only possibly useful advice I can give concerning your Linux version is making sure that the results of MLName were treated as read-only. Perhaps try casting the result to const char *, and see if your compiler is flagging any warnings about const usage. I obviously can't comment on your Windows problems without more information. > 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. To do this, you should use MLReady(). MLReady(), when called on a link which hasn't passed the MLConnect() stage yet, indicates whether someone has tried to connect to the link or not. You can keep polling until the other side is ready. Or, if you don't mind having your program block, then go ahead and call MLConnect(). MLConnect() will keep blocking until the other side has also connected (if you do this, it's a good idea to make sure you explicitly call MLConnect() on both sides instead of relying on implicit calls). > 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. Assuming that my response has been unhelpful to you, let's go ahead and discuss your sources privately. > > Best regards > Jens Sincerely, John Fultz jfultz@wolfram.com Front End Group Wolfram Research, Inc.