There are actually two exceptions occurring: One is the Ctrl-C, which as
you correctly say, will probably delayed until there is a `check' in the
interpreter (see also David Beazley's wonderful presentation on the
GIL). The other one is the exception that is generated in the IPC code
by returning a NULL. This one should caught by the except clause.

As the call to sem.acquire releases and reacquires the GIL, I think
signal processing will be done immediately. This causes the
KeyboardInterrupt exception to occur immediately i.e. to interrupt the
handling of the other exception.

import posix_ipc
import signal

sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX)
signal.signal(signal.SIGINT, lambda sig, frame: None)
status = []
try:
    status.append("Trying")
    sem.acquire()   # User hits Ctrl + C while this is waiting
    status.append("Acquired")
except:
    status.append("I caught it!")
print status

sem.close()
sem.unlink()

prints: ['Trying', 'I caught it!']

I also tried some other variants, catching the KeyboardInterrupt at
various places:

This one prints: ['Trying', 'Keyboard Interrupt']
This suggests to me that the first exception handling is aborted by the
Ctrl-C handling.

import posix_ipc

sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX)

status = []
try:
    try:
        status.append("Trying")
        sem.acquire()   # User hits Ctrl + C while this is waiting
        status.append("Acquired")
    except:
        status.append("I caught it!")
except KeyboardInterrupt:
    status.append("Keyboard Interrupt")
print status

sem.close()
sem.unlink()

And this one prints: ['Trying', 'I caught it!']

import posix_ipc

sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX)

status = []
try:
    status.append("Trying")
    try:
        sem.acquire()   # User hits Ctrl + C while this is waiting
        status.append("Acquired")
    except KeyboardInterrupt:
        status.append("Interrupt")
except:
    status.append("I caught it!")
print status

sem.close()
sem.unlink()

I was actually a bit surprised that the addition of the try/except
KeyboardInterrupt helps solve the problem but that apparently the
exception handler is not executed.

Folding the two try's into one with two except clauses will not help as
there are indeed two exceptions to be handled.

I also added traceback printout in the outer exception handler and it
points to the sem.acquire line.

My conclusion is that if there are two exceptions at the same time, the
inner exception handler is interrupted by the other exception even
before the except clause can be entered. And only the outer one is
really executed. This explains the behaviour that the OP described.