Brian J. Watson wrote:
> Andreas wrote:
>> I did write two classes. On of them is a interface to OpenSSI. At the
>> moment it only provide the clustername, the actual nodenumber and a
>> list of all the nodes in the cluster. The other one uses this
>> information to create two semaphore on different nodes (if available)
>> and provide p und v operations for failsave mutex. I think it is
>> working, but I haven't tested it yet. Maybe there are still errors in
>> the implementation. I don't know if I can look over it at them moment,
>> because the idea of javaspace seems very interessting to me. In the
>> attachment I have the class and the native c code for the OpenSSI
>> interface. It is working for the function I told.
>> I have attached this files to this mail.
> I know very little about writing Java bindings, but it looks good.
>> I think it would really be an good idea to have an java interface to
>> all the openSSI functions.
> I agree. This and any other language bindings should be distributed with
> libcluster. A reasonable place for this to go in the repository would be
> ci/cluster-tools/libcluster. Before it can be checked in, however, the
> necessary rules need to be added to
> ci/cluster-tools/libcluster/Makefile.am, which looks a bit different
> from a static Makefile like the one you provided.
I only made that makefile to try out but it should be simple to change
it. I didn't use native Java before, too. The shared library must not be
copied to /usr/lib it only must be in the library path of the java
programm that uses OpenSSI functions. So it should maybe be in another
>> If in the near future ( ;-) ) process migration for threads will be
>> possible that could of course be nice to have.
> It wouldn't be terribly difficult to make threads migrate together, but
> splitting up threads between different nodes won't happen anytime soon.
> Splitting up threads is not desirable, since memory sharing performance
> would fall into a hole.
Is there any planed implementation where whole processes that contain
threads are migratable?
> Thanks for the contribution,
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.