CLIPC SMFIFOs

I posted some ideas for a new CLIPC feature that I am currently calling "shared memory FIFOs". For those who are interested, please take a look at the posting on the SourceForge site and post any thoughts, concerns, etc.

The link is:

http://sourceforge.net/apps/wordpress/clipc/2009/06/29/smfifos/

(Note: this link previously pointed to a page that asked you for a password. It has been updated so that it no longer does that.)

New CLIPC Site

I am gradually going to be moving all things CLIPC to the SourceForge site. In particular I am hoping to create some basic documentation on how to use CLIPC and its various components to the blog associated with that project.

The CLIPC site is at http://clipc.sourceforge.net
The CLIPC blog is at https://sourceforge.net/apps/wordpress/clipc/

CLIPC 0.2 up on SourceForge

The new and improved version of CLIPC is now available on SourceForge. This new version includes, among other things, non-blocking FIFOs.

Xming Locks!

Short Story

Starting up the gnome session manager from within a gnome-terminal avoids the annoying "Not Responding" problem that I get when going from Vista to Linux via XMing.

Long Story

Briefly, here is what I did to get it to work:

• Start Xming without access control
• SSH to the Linux system and set DISPLAY
• Start a gnome-terminal
• From within the gnome-terminal, start a gnome-session

Background

This is using XMing 6.9.0.31 to display something from Fedora Core 10 (2.6.27.19-170.2.35.fc10.i686) on Vista Home Permium.

For reasons unknown (anyone here with info, please comment), XMing seems to lock up on Vista frequently. After as little as 10 seconds, the main window stops responding to requests.

I would set up XMing using the configuration that I outlined in a previous post.

Xming after a few seconds

Start Xming without access control

I'm not exactly fond of this, but unfortunately I did not find a way around this. If I do, I will post this info in a followup.

XLaunch dialog

This results in the rather...blank Xming display:

Blank and not very useful

SSH to the Linux system and set DISPLAY

Using putty or whatever, log onto the Linux system. Note that this is using SSH, telnet, but not with something graphical like an xterm.

Next set the X-Windows environment variable, DISPLAY, to point back to the Vista system. I'm sure there's some way of doing this with a script, but I'm too lazy to figure it out.

Setup the DISPLAY variable

Start a gnome-terminal

I expect that xterm or kdeterm or others would do just as well, but my system only seems to have "gnome-terminal." This should result in an unadorned, ugly, terminal appearing on the Vista system:

Note the lack of border and resize.

From within the gnome-terminal, start a gnome-session

Emphasis on from within the gnome-terminal! I've tried doing this from the SSH session and it does not seem to work. Don't ask me why... it's just Linux!

Once again, perhaps this may work using the KDE equivalent, but this is what I use.

After starting up a session, the Xming display changes from the ugly default to something better looking:

Note the window now has a window bar, border and the background has changed.

gnome-session also spouts about a page and a half of scary-looking gibberish. The thing seems to work despite all this.

Conclusion

Using this approach, Xming is much more responsive than with the other approaches I've tried. It is somewhat cryptic, and various steps may not even be necessary. If you find other approaches that work, please post them.

JNI/Windows Gotchas: UnsatisfiedLinkError

The Short Story

This post describes a solution that has worked for me when I get a an UnsatisfiedLinkError on Windows using MingW, while developing a JNI library.

The Long Story

Java Native Interface (JNI) development on Windows is extremely annoying. There are all kinds of land mines strewn randomly about the landscape to snare the wary and unwary alike. Any one of these issues can require hours of hair-tearing in order to get things to a working state.

After dealing with enough of these, I decided to post some of the solutions I've found in order to save others from premature baldness. For today's entertainment, I have selected the infameous UnsatisfiedLinkError.

java.lang.UnsatisfiedLinkError: no found in java.library.path

This is caused by not having the DLL that contains your C/C++ code in the path that Java is using to find it. If you have this problem, try this:

• Bring up the properties for the project containing the native declarations
• From the properties dialog, bring up the build path for the project.
• From the build path properties, edit the native libraries location for the project.
• From the resulting dialog, select the folder where your DLLs live

Bring up the properties for the project containing the native declarations

For example:

For the CLIPC project, this is clipc-java. You can be sure by selecting the Java project that contains the .java files with declarations like this one:

From the properties dialog, bring up the build path for the project.

For example:

From the build path properties, edit the native libraries location for the project

For example:

From the resulting dialog, select the folder where your DLLs live

For example, this tells Eclipse to look in the workspace:

Then this tells Eclipse where to look for the DLL:

Conclusion

If you have an UnsatisfiedLinkError, you may need to tell Eclipse where your DLLs live. This post gives a step-by-step on how to do that.

XMing Rocks (yes, it does)!

The gnome windows manager desktop on Fedora 10

Short Story

If you need to develop on Windows and Linux, XMing will allow you to run programs on a Linux box and display them on a Windows machine.

Long Story

As the chief architect, engineer, and only developer on the CLIPC project, I need to be able to develop on Linux and Windows. Developing on Linux has been something of a chore up until now, because I had to either "rlogin" onto the machine, and give up any GUI capabilities, or physically sit in front of the system.

Cygwin-X

I've been trying to get a better setup for a couple of days and then I hit on the idea of using the ability of X-Windows to forward a display to another machine. One of the (many) problems that I encountered was getting an X-Windows server to actually run on Windows.

At first I tried to use Cygwin-X, the x-windows that comes with Cygwin, but I found it difficult to use. Any time I run a program and it seems to do nothing, I start getting testy. Specifically, I selected

 Start>Cyginw-X>Start XWin Server

After a bit of puttering about, I recalled running "startx" from the keyboard. I tried that from a Cygwin session and was "rewarded" with this:

Ugh...this actually makes Windows look good!

At this, I felt like I had been thrown into a time warp back to the 90's when you could peg the CPU of a machine running X by just bringing up a menu.

Mind you, I have tremendous respect and gratitude towards the folks who maintain cygwin. But there are limits.

Enter XMing

After glaring at Cygwin-X for a bit, I tried looking for something else. Google, after much prodding and use of something-or-other: directives turned up XMing.

I've been using MinGW for quite a while in general, and for the Windows portion of CLIPC in particular, so I am reasonably comfortable with things MING. I downloaded it and installed it in under 10min. Perhaps under 5min.

With most things Linux-like I expect stuff to take at least a weekend, so this was a very nice surprise.

At first I got the same, ugly X-Windows starting stuff, but with a little bit of reading, I determined how to fire up the gnome window manager. The way to do this is to specify "gnome-terminal" as the "start program" that you get from running XLaunch.

In the interest of being more helpful, here is what I used for the values in the XLaunch config screens:

For me the most important aspect is that it can run Eclipse. I want to have some vague confidence that my stuff will compile and run on the Linux version.

Eclipse running on Linux and forwarded to Windows

Conclusion

MingX is a user-friendly solution for those who want to forward X-Windows from a Linux box to a Windows box.

CLIPC File Naming

NOTE

The source code shown here may not be up on SourceForge until 4/23/2009 (Friday). This is due to some last minute problems found with the Linux code. I'll provide more information as it becomes available.

The Short Story

CLIPC uses file names to identify IPC resources. If two processes use the same file name for a Semaphore, they get connected to the same Semaphore.

The Long Story

You can find the source code and examples for CLIPC on SourceForge.

Naming: The Orphan Child of IPC

It seems to me that a great deal of effort has gone into ensuring that various IPC schemes are "correct" or that their waiting schemes are "fair," while somewhat less effort has gone into ensuring that they are easy to use. In particular, how do two processes that have no prior association connect in order to communicate?

Different platforms use different schemes for dealing with this problem. For semaphores, Windows has a "namespace" set aside for Semaphores and a bunch of other objects. In Linux there are several approaches. One of them is to use a restricted name space, another is to use integer values to identify the Semaphore.

File Names: a Ubiquitous Concept Across Platforms

A lot of effort during the design and evolution of Java to make file naming across platforms easier. For example, the path "/what/ever/one" will work on both Linux and Windows.

CLIPC builds on that strength in order to solve the naming problem for some IPC mechanisms.

In the case of Semaphores, CLIPC uses a file name to identify which Semaphore a client wants to use. If two processes use the same file name when creating a Semaphore, the two processes will end up connected together through that semaphore.

A nice side-effect of using file names to identify resources is that it solves the problem of who can use the resource. For example, if a client does not have permission to read a file associated with a semaphore, then they cannot access the associated semaphore.

Semaphore File Naming in CLIPC

In CLIPC, a client must specify a file name in order to connect to a Semphore. Here is an example where the file name is specified when the constructor is called:

Semaphore s = new Semaphore("/mysem");

Here is an example where the file name is specified when the Semaphore is connected to the underlying system resource:

Semaphore s = new Semaphore();
...
s.connect("/mysem");

CLIPC uses the name of the file to store a value that, when used in the underlying system call, will identify a Semaphore to the platform. If such a file exists at the time when the connection occurs, CLIPC will use the contents of the existing file instead of creating a new file.

File Creation and Race Conditions

Such a scheme has an inherent race condition in that if two processes decide to create the file at the same time, it is possible that both with think they were successful, yet each is using a different underlying identifier.

CLIPC handles this problem by using a two step process:

• Create a temporary file and populate it with an identifier
• Rename the temp file to the desired file name

For windows and Linux, renaming can be an atomic operation. In particular, it can be made to fail if the desired name is already being used. This ensures that in the case where two processes try to create the file at the same time, only one will succeed.

Conclusion

CLIPC uses file names for handling the issue of identifying which IPC Semaphore a client wants to use. File names are ubiuitous across platforms that Java supports, making them convenient for use as IPC "names." CLIPC uses files with semaphores to store the underlying platform ID for a semaphore.