Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1998
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

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.
-  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.
> 



  • Prev by Date: Re: How do you draw Triangles and other Geometric figures in Mathematica?
  • Next by Date: My own sum
  • Prev by thread: Re: MathLink portnumbers and internal types
  • Next by thread: Re: Re: MathLink portnumbers and internal types