2015-01-02 18 views
20

Quando compilo un programma usando la funzione POSIX sem_init(), ricevo un avviso di compilazione (errore perché di solito uso -Werror) che la funzione è stata deprecata quando compilo su Mac OS X 10.10.1 (Yosemite) con GCC 4.9.1 o la versione di Clang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)) da XCode 6.1.1. Una rapida occhiata a /usr/include/sys/semaphore.h mostra che la funzione ha effettivamente un tag __deprecated dopo la sua dichiarazione, così come sem_getvalue() e sem_destroy().Perché sem_init(), sem_getvalue(), sem_destroy() sono deprecati su Mac OS X e cosa li sostituisce?

Domande:

  1. dato che non v'è alcun accenno di disapprovazione nella specifica POSIX, perché sono queste tre funzioni individuate come deprecato su Mac OS X?

  2. Dato che sono deprecati, qual è la sostituzione e perché è la sostituzione preferita?

(ho controllato Ask Different prima, non ci sono domande taggati e senza domande che chiedono sul sistema deprecato chiamate - solo programmi.)

+0

correlati a http://stackoverflow.com/questions/1413785/sem-init-on-os-x e http://stackoverflow.com/questions/16655153/sem-getvalue-dysfunctionality-in-mac-os -xc/16655541 # 16655541? –

+1

@IskarJarak: Il primo di questi due sembra coprire il mio problema in pratica, sebbene ci sia ancora "perché" (come in "perché Mac OS X non supporta i semafori senza nome?) Che non è risolto. Poiché il mio codice non era in fase di compilazione, non stavo arrivando al punto di un errore ENOSYS dalla funzione 'sem_init()' –

+0

Un'altra fonte forse forse più canonica di una risposta può essere trovata tramite https: // devforums .Mela.com nella sottosezione "Core OS" di "Mac Development". –

risposta

21

mi sono imbattuto in questo problema io stesso quando si cerca di porto una libreria a cui stavo lavorando su OS X. Ho cercato per un po 'senza trovare una risposta eccellente. Quando ho trovato la risposta, ero un po 'turbato: la risposta è effettivamente "if Apple implemented POSIX unnamed semaphores, how many X Serves would you buy?".

di riassumere i punti di questo che sono deprecati e perché alcune delle funzionalità rimane lettera morta:

  • Appendice 9 della Single UNIX Specification afferma che non sono interfacce obbligatorie
  • "La maggior parte dei codice portabile" usi semafori SYSV
  • compatibilità con POSIX chiamati i semafori, che condividono il tipo sem_t è difficile

Per quanto riguarda invece cosa fare, sono andato con i semafori GCD. Per quanto riguarda il motivo per cui è preferibile la sostituzione: è l'unica interfaccia di semaforo non denominata nativa disponibile su OS X vanilla. Apparentemente GCD li ha aiutati a vendere più X Serves. Temo che non ci sia una risposta migliore.

Tuttavia, si spera che alcuni codici siano utili. Il risultato di tutto questo è che avete in modo efficace per implementare la propria interfaccia semaforo portatile:

#ifdef __APPLE__ 
#include <dispatch/dispatch.h> 
#else 
#include <semaphore.h> 
#endif 

struct rk_sema { 
#ifdef __APPLE__ 
    dispatch_semaphore_t sem; 
#else 
    sem_t     sem; 
#endif 
}; 


static inline void 
rk_sema_init(struct rk_sema *s, uint32_t value) 
{ 
#ifdef __APPLE__ 
    dispatch_semaphore_t *sem = &s->sem; 

    *sem = dispatch_semaphore_create(value); 
#else 
    sem_init(&s->sem, 0, value); 
#endif 
} 

static inline void 
rk_sema_wait(struct rk_sema *s) 
{ 

#ifdef __APPLE__ 
    dispatch_semaphore_wait(s->sem, DISPATCH_TIME_FOREVER); 
#else 
    int r; 

    do { 
      r = sem_wait(&s->sem); 
    } while (r == -1 && errno == EINTR); 
#endif 
} 

static inline void 
rk_sema_post(struct rk_sema *s) 
{ 

#ifdef __APPLE__ 
    dispatch_semaphore_signal(s->sem); 
#else 
    sem_post(&s->sem); 
#endif 
} 

questo era il set minimo di funzionalità che mi interessava; le tue esigenze possono variare. Spero che questo sia utile.

+1

Penso che vorrei aggiungere la funzione destroy al set, ma questo è un utile punto di partenza. Grazie. –