POSYBL(1L) Misc. Reference Manual Pages POSYBL(1L)
NAME
posybl - library routines for using the POSYBL (a free Linda
implementation for Unix Networks)
SYNOPSIS AND DESCRIPTION
These routines implement the Linda model of paralleling pro-
gramming and allow C programmers to issue tuple space opera-
tions to the Tuple Managers.
init(rungroup, nodefile)
int rungroup;
char *nodefile;
Specifies that this process belongs to the rungroup
--------
POSYBL Program and that is going to load the node list
from the file nodefile. In case, nodefile is NULL the
-------- --------
routine searches for the file ~/.nodefile and if not
found for ./.nodefile. If this routine is not called,
the process rungroup is supposed to be 0 and the
default files are loaded.
out(tuple description)
Write a tuple to the tuple space. The tuple descrip-
tion is given by the use of the field description func-
tions.
in(template description)
rd(template description)
Request a tuple that matches the template from the
tuple space. With in(), the tuple is deleted from the
tuple space. With rd(), it remains. The template
description is given by the use of the field descrip-
tion functions. You must remember that the first field
of a template is should always be an actual since it is
used as a key for storing the tuples in a hash table.
eval l(arg0, arg1,...,argn, NULL),
-
char *arg0,...,*argn;
eval v(argv)
-
char **argv;
eval nl(node, arg0,...,argn, NULL)
-
char *node, *arg0,...,*argn;
eval nv(node, argv)
-
char *node;
char **argv;
A 'rsh' invocation of an executable. It's doubtful, if
you can call this function eval(). The first two forms
invoke the executable in the least loaded node, if the
nodes support get rusage() calls or the one with the
-
SunOS 5.5.1 Last change: 9 March 1991 1
POSYBL(1L) Misc. Reference Manual Pages POSYBL(1L)
highest preference value otherwise. In the last two,
the node must be specified by the user. You should
remember that the programs started with this way can
print in the terminal but they cannot wait for input
from the terminal. All input to them should either
from the arguments to these calls or through the tuple
space (the initial process should ask for input and
then would send it to the one that needs it).
l<type>(var);
<type> var;
ql<type>(varptr);
<type> *varptr;
ln<type>(array, length);
<type> *array;
int length;
ln<type>(arrayptr, lengthptr);
<type> **arrayptr;
int *lengthptr;
Field description functions. They are used to describe
the fields in a tuple access call. The <type> can be
----
one of char, short, int, float, double and string. The
---- ----- --- ----- ------ ------
form l<type> specifies that a field is a scalar actual
- ----
field. The argument var to these routines is a vari-
---
able (or constant) of the appropriate <type> The form
----
ql<type> specifies that a field is a scalar formal
-- ----
field. These routines are used to describe the formal
fields, only, of a template, since formal fields are
not allowed in tuples. The argument varptr to these
------
routines is the address of a variable of the
corresponding type and in which the tuple's data will
be copied. If you are not interested in the data, you
should pass the NULL pointer as argument. The form
ln<type> specifies that a field is a vector actual
-- ----
field. The argument array to these routines is a
-----
pointer to a data area that contains length elements.
------
We must note that the <string> scalar type doesn't have
------
a corresponding vector type. The form qln<type> speci-
--- ----
fies that a field is a vector formal field. The argu-
ment arrayptr is the address of a pointer to the
--------
corresponding type and the argument lengthptr is the
---------
address of an int, in which the number of elements of
the array will be copied. If you are not interested in
the data and/or their length, you should pass the NULL
pointer as argument. The address in arrayptr is in a
--------
static area that will be overwritten after another call
to in(), rd() or out(). In order, to pass user defined
structures a simple way is the following:
struct ex {
int iv;
SunOS 5.5.1 Last change: 9 March 1991 2
POSYBL(1L) Misc. Reference Manual Pages POSYBL(1L)
float fv;
char *st;
};
#define lex(a) lint(a.iv),lfloat(a.fv),lstring(a.st)
#define qlex(a) qlint(&((a)->iv)),qlfloat(&((a)->fv)),qlstring(&(a)->st)
struct example tst;
out(lint(10), lex(tst));
in(lint(10), qlex(&tst));
copychars(dest, src, len)
char *dest;
char *src;
int len;
copyshorts(dest, src, len)
short *dest;
short *src;
int len;
copyints(dest, src, len)
int *dest;
int *src;
int len;
copyfloats(dest, src, len)
float *dest;
float *src;
int len;
copydoubles(dest, src, len)
double *dest;
double *src;
int len;
Analogous to memcpy() function. Copy len elements from
---
src to dest. In fact, copychars() is a direct call to
--- ----
memcpy(). But, copyints() is generally faster than
memcpy() and I find them more convenient than memcpy().
timer start();
-
timer split(str);
-
char *str;
print times();
-
These routines are intended for gathering timing infor-
mation about your program. The routine timer start()
-
resets the system. The routine timer split() keeps a
-
note of the time it is called and attaches str to it as
a label. The routine print times() prints the notes it
-
has kept by the time it is called. Time information is
kept in elapsed time. up to 32 time notes can be kept.
FILES
~/.nodefile,
SunOS 5.5.1 Last change: 9 March 1991 3
POSYBL(1L) Misc. Reference Manual Pages POSYBL(1L)
./.nodefile
SEE ALSO
NodeFile(1L), startup(1L), system(1L), tmanager(1L)
BUGS (Some call them features)
Numerous, I guess. I just haven't find them yet.
AUTHOR
Ioannis Schoinas, sxoinas@csd.uch.gr
ACKNOWLEDGEMENTS
I would like to thank everybody that helped me in writing
this program and especially I. Kavaklis for offering his
ideas, some pieces of code, demo programs, and for being the
first subject to test this system.
NOTE
Linda, is a trademark of SCA, Inc.
SunOS 5.5.1 Last change: 9 March 1991 4