This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Problem with system V shmem between JNI process and regular processes

First I would like to say that y'all are doing a great job with Cygwin...
I am new to cygwin and gnu, and have started working on porting a large
printer driver (moved to ASPI) multiple process application and UI to NT from
The UI is already written in Java and access to the printer processes and device

driver are via JNI calls to system V shared memory routines.
The cygwin32_ipc-1.03 downloaded from the net works fine between all of the
processes that are all started up by any of the bash shells available with Cygwin.

The Java application can also make it's own section of shmem and access it's
shmem area fine.  The java vm is also started from bash.
The ipcs command from a bash shell can even see the allocation made as a result

of the JNI calls and the printer application calls.
My problem is that shmget fails from either side ( depending on which starts
up first )
when I try to use the same key from both Java JNI calls and the ported unix
process sides.
The errno returned is 12 Not enough memory.
If someone knows what I can do to fix this I would greatly appreciate it.  All
calls I make to the Cygwin API work fine across JNI thanks to all of the net
BTW. In the Unix implementation the key was made up of the uid from getuid.
debug printfs show that the result is different if run from bash or through
JNI.  500 in
the first case and ffff in the second.  This feature is easy to remove but I
was wondering
if that was a possible cause of the ipc problem I'm also having??
John H. Fralinger         |   
SW Contract Engineer      |      1-610-255-5607
Research & Development    |

Want to unsubscribe from this list?
Send a message to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]