Paul Davis wrote:
>>> the problem with semaphores is that Unix/POSIX semantics don't allow
>>> integration of a process sleeping on an file descriptor and a
>>> semaphore (one of the few areas where Windows definitely improves upon
>>> Unix). this would mean adding yet another thread that just sleeps on
>>> the semaphore used to drive the "process" callback. Not terrible, but
>>> not particularly great either. The code would be a little cleaner, but
>>> we'd have an extra thread for every client. Uhm.
Hi,
I just wanted to make sure I understood that. (I might learn something
here). First, I guess SysV uses semget(2), semctl(2) and semop(2) to
handle semaphores. Does that mean that the following code would not be
correct:
struct sembuf g_lock_sembuf[1];
struct sembuf g_unlock_sembuf[1];
g_lock_sembuf[0].sem_num = 0;
g_lock_sembuf[0].sem_op = -1;
g_lock_sembuf[0].sem_flg = 0;
g_unlock_sembuf[0].sem_num = 0;
g_unlock_sembuf[0].sem_op = 1;
g_unlock_sembuf[0].sem_flg = 0;
....
semop(g_sem_id, g_lock_sembuf, 1); /* lock semaphore */
len = read(fd, buf, len); /* might block */
semop(g_sem_id, g_unlock_sembuf, 1); /* unlock semaphore */
What could go wrong?
Do the same restrictions apply with the pthread semaphores
(semaphores(3), semaphore.h) or the pthread mutexes?
Thanks for the help!
Peter
