POSIX semaphores and Kernel 2.4.7, glibc 2.2.4 (RedHat 7.2)

POSIX semaphores and Kernel 2.4.7, glibc 2.2.4 (RedHat 7.2)

Post by Brice Breede » Sat, 03 Nov 2001 06:45:44



Does anyone know if POSIX semaphores can be shared between processes
on newer versions of Linux, such as RedHat 7.2 (kernel 2.4.7 & glibc 2.2.4)?
I'm currently using RedHat 7.1 and POSIX semaphores couldn't be shared at
that time.
 
 
 

POSIX semaphores and Kernel 2.4.7, glibc 2.2.4 (RedHat 7.2)

Post by Rick Ros » Thu, 08 Nov 2001 07:47:36


Quote:> Does anyone know if POSIX semaphores can be shared between processes
> on newer versions of Linux, such as RedHat 7.2 (kernel 2.4.7 & glibc 2.2.4)?
> I'm currently using RedHat 7.1 and POSIX semaphores couldn't be shared at
> that time.

I haven't had a chance to try spanning processes with POSIX Semaphores
yet, but I have been able to span processes with POSIX Mutexes. In order
to do so, I had to do two things:

1) Recompile the kernel to enable Virtual Memory File System
2) Mount a shared memory file system (shmfs) (usually /dev/shm)

HTH

Rick
Co-author Kylix Development by Wordware Publishing ISBN: 1556227744

 
 
 

1. Problem with TCP/IP Sockets read returning 0's - Redhat 7.2 - glibc

(Originally posted to comp.os.linux.development)

Hello All,

I have an application that reads and writes from TCP/IP sockets. I know that
according to the spec, TCP/IP sockets should be 100% guaranteed. That is, if
I write "hello world" to one side of the socket, I should be able to always
read "hello world" from the receiving side of the socket.

What we are seeing is that occasionally a read of the socket will return the
correct size of bytes (ie. 11 as in the "hello world" example), but the data
will be all hex 0's. We prefill the receiving data area with bogus
characters and immediately check it after the read and it will be all 0's so
we know the received data is 0's. Now it doesn't do this all the time, just
occasionally and usually only when we are doing a lot of writes on the
socket with no time delays between the writes.

If we insert a delay of some time, either a sleep() or usleep(), etc., then
the 0's go away. It is almost as if we are overrunning the buffer for the
socket. I just thought with TCP/IP that this was impossible.  The
application receives messages from client programs and is relaying them
using TCP/IP sockets to another program. It is trying to relay them as fast
as possible, ie. write them out one after the other on the socket.

As the subject indicates, this is on Redhat 7.2 using the glibc libraries
and gcc as the compiler. The computers using the sockets are on the same
network hub.  If it is a buffer problem, shouldn't the write() return an
error indicating to us that we are overflowing the network buffer? We tried
doing read() and recv() on the receiving end and the problem appeared with
both functions.

Any help would be appreciated.

Jim

2. free SMS sender program

3. Redhat 6.2 with kernel 2.4.x or Redhat 7.2 ?

4. get 'OK' prompt when resetting serial console

5. Sys V Semaphores vs. POSIX Semaphores??

6. auto.direct yellow-pages map

7. redhat glibc dist - where the heck is posix lib?

8. Unix - Frequently Asked Questions (5/7) Digest [Frequent posting]

9. configuring gcc-2.7.2.x on redhat 7.2

10. RedHat 7.2 on THinkPad 7.2

11. ppp server problem with Redhat 7.2 Kernel 2.4.7-10

12. Upgrade kernel RedHat 7.2 / onboard HPT370

13. Problems compiling RedHat 7.2 with new kernel