MathGroup Archive 1998

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: MathLink portnumbers and internal types

> 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

I obviously can't comment on your Windows problems without more

> 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


John Fultz
Front End Group
Wolfram Research, Inc.

  • Prev by Date: Re: Get rid of Input cells when printing?
  • Next by Date: Re: How can I use Signal Processing 2.9.5 under Mathematica 3.0
  • Prev by thread: Re: Re: MathLink portnumbers and internal types
  • Next by thread: Re: MathLink portnumbers and internal types