Newsgroup: it.comp.os.linux.development
Titolo: segnali

salve, 
sto iniziando la programmazione concorrente e vorrei chiarire un punto:
mi pare d'aver capito che se dei processi applicativi vogliono 
comunicare (forse sarebbe + corretto dire 'sincronizzarsi')ricorrendo
ai segnali occorre usare i segnali SIGUSR1/2.
Non è dunque possibile che un processo invii ad un altro processo un
altro tipo di segnale come, ad esempio, SIGALARM?
Faccio un esempio:
un processo P0 può ricevere segnali da altri 3 diversi processi:
P1,P2 e infine P3.
A seconda che riceva un segnale da P1 (che invia SIGUSR1) o da P2 ( che 
invia SIGUSR2) o da P3 (che potrebbe per es. inviare SIGALARM) esegue
3 differenti azioni.
Se però i processi possono inviarsi solo SIGUSR1/2 questa idea è 
inapplicabile (farò ricorso alle IPC ok, ma il tutto s'appesantisce 
un po')
Ho capito giusto?
                           Chef

 altro tipo di segnale come, ad esempio, SIGALARM?
Certo che si:
man 2 kill
Alessandro.

test ha scritto:

In pratica allora dovrei semplicemente definire un opportuno gestore
del segnale che invio, ad esempio SIGALARM piuttosto che SIGINT o
chissà che altro, in maniera da ridefinire il comportamento di default
che l'arrivo di questo segnale produrrebbe, giusto?
Ma poi, visto che ci siamo, quale sarebbe il comportamento che di 
default terrebbe un processo all'arrivo dei segnali SIGUSR1/2?
Lo so' dovrei fare un programmino del cavolo e vedere che succede,
ma sono le 2:45 e francamente non mi va......
Grazie
			Chef

 			Chef
Uhm... non mi pare una buona giustificazione... "a me non va di provare, 
ditemelo voi" :P
Cmq mi pare che, per questi segnali, il processo venga killato. Dovrei 
provate pure io, ma non ne ho voglia.
Anyway, metti che tu voglia usare solo i SIGUSR1/2, e devi codificare 
piu' di 2 messaggi, basta che mandi _sequenze_ di SIGUSR1/2. Ad es:
SIGUSR1+SIGUSR1 = messaggio da P1
SIGUSR1+SIGUSR2 = messaggio da P2
SIGUSR2+SIGUSR1 = messaggio da P3
Puoi estendere questo procedimento ad una lunghezza di signal 
arbitraria... in pratica, puoi arrivare ad interpretare SIGUSR1=0, 
SIGUSR2=1, e mandi stringhe binarie di lunghezza prefissata. Ovviamente, 
portato all'estremo, questo e' un sistema _MOLTO_ inefficiente per 
comunicare :P
-- 
Mat/tia Belletti - Undergraduate student @ 
cs.unibo.it
ICQ: 33292311    - email: 
mbel...@cs.unibo.it
IRC: RedGlow     - site(s): 
http://www.cs.unibo.it/~mbellett
Linux registered user 299762 @ Linux registered machine 213003

 comunicare :P
Mi sembra che quest'idea comporti un problema:
poniamo che P0 riceva SIGUSR1+SIGUSR1.
Cosa gli assicura che il secondo SIGUSR1 provenga da P1 piuttosto che 
da  P2? Il processo ricevente non ha modo di sapere il mittente del
segnale.
Mi viene in mente di inserire all'interno di regioni critiche l'invio
di tali serie di segnali ma a questo punto ho un ulteriore dubbio
(che palle lo so', ma scusate sono proprio agli inizi e magari 
rischio pure di dire qualche idiozia):
ricorrendo alle regioni critiche garantisco che l'INVIO della serie
di segnali avvenga in modo 'non interlacciato' ma riesco a garantire
che anche la RICEZIONE=rilevamento della serie di segnali sia non 
interlacciata?
E poi comunque dovrei far ricorso ai semafori, cosa che volevo 
vitare per non appesantire troppo la mia applicazione.
Thanx
		Chef

 SIGUSR2+SIGUSR1 = messaggio da P3
Non sono affatto sicuro che con l'invio di segnali multipli questi non
vadano persi o vengano consegnati nello stesso ordine con cui sono partiti.
Alessandro.

 altro tipo di segnale come, ad esempio, SIGALARM?
sigalarm è un po' sfigato, perché viene usato in alcune versione della
libc per implementare alcune funzioni di sleep.....


Se non usi segnali real-time di certo no. Segnali multipli saranno 
senz'altro persi.
Ciao
Simone

 Cmq mi pare che, per questi segnali, il processo venga killato. Dovrei 
Esatto. Da man 7 signal:
[...]
      The  entries  in  the  "Action" column of the table specify the default
      action for the signal, as follows:
      Term   Default action is to terminate the process.
[...]
       Signal     Value     Action   Comment
       ---------------------------------------------------------------------
[...]
       SIGUSR1   30,10,16    Term    User-defined signal 1
       SIGUSR2   31,12,17    Term    User-defined signal 2
-- 
addio, e grazie per tutto il pesce

 segnale.
Ce ne e` un'altro e piu` basilare, e cioe` che con buona probabilita` il 
processo di destinazione ne vedra` comunque uno solo. Se si vogliono 
fare di queste cose si devono usare i segnali real time (che supportano 
anche l'informazione di chi te lo ha mandato il segnale).
Ciao
Simone