Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Gigabyte MO32U24 OLED: il 4K a 240Hz su un pannello OLED ideale per il gaming
Gigabyte MO32U24 OLED: il 4K a 240Hz su un pannello OLED ideale per il gaming
Pannello QD-OLED da 32 pollici con risoluzione 4K, frequenza di aggiornamento a 240Hz e tempi di risposta rapidissimi: il Gigabyte MO32U24 evolve il progetto del suo predecessore MO32U e alza ulteriormente l'asticella delle prestazioni. È ancora una volta un monitor indirizzato ai giocatori più esigenti
Recensione realme 16 5G: lo smartphone con Selfie Mirror ha una batteria da 6550mAh
Recensione realme 16 5G: lo smartphone con Selfie Mirror ha una batteria da 6550mAh
realme 16 5G è un nuovo smartphone con sensore Sony IMX 852 da 50MP sul retro e uno specchio selfie fisico integrato nella camera bar, una prima nel segmento di mercato. Batteria da 6550mAh in un corpo da 8,1mm e 183g, certificazione IP69K e ricarica da 45W completano un pacchetto aggressivo per la fascia media, per uno dei prodotti più interessanti del produttore sul piano commerciale
Come rispettare tutte le nuove regole per i monopattini elettrici? La guida per non rischiare sanzioni
Come rispettare tutte le nuove regole per i monopattini elettrici? La guida per non rischiare sanzioni
Sono ormai definitive le nuove norme del Codice della Strada per i monopattini elettrici. Non solo targa e assicurazione, le regole sono tante e riguardano diversi aspetti, vi spieghiamo come evitare sanzioni che possono essere salate
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 01-09-2004, 13:44   #1
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
[C] IPC con code di messaggi

[C] IPC con code di messaggi

Ciao, per un esercizio per l'università devo far comunicare vari processi attraverso code di messaggi, utilizzo le seguenti funzioni per inviare e ricevere un messaggio:

int msgsnd(int msqid, const void *msgp, size_t msgsz,
int msgflg);

int msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp,
int msgflg);

e questa struttura dati per il messaggio

struct mymsg {
long mtype; /* message type */
char mtext[MSGSZ]; /* message text of length MSGSZ */
}

Tutto come da manuale insomma. Il mio problema è che inizialmente il messaggio è costituito da un solo carattere, poi però la dimensione cresce non linearmente praticamente moltiplicata sempre per sei. Avrò quindi con pochi cicli msg costutuiti da stringhe da 1,6,36,216,1296 ecc caratteri... e una struttura come char mtext[MSGZ] non è adatta giusto? E poi che valore dovrebbe assumere MSGZ? Nell esercizio non è specificato quante iterazioni devo compiere, credo il numero sufficiente per dimostrare una corretta comunicazione. Come fare considerando che la funzione msgrcv deve conoscere la dimensione del messaggio?

Grazie
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 01-09-2004, 15:52   #2
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
MSGZ è arbitrario ed è specificato in msgsz.
Che documentazione hai letto? La mia è leggermente differente...
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 01-09-2004, 16:53   #3
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
Intanto grazie... io sto prendendo come riferimento questo sito

http://www.cs.cf.ac.uk/Dave/C/node25...00000000000000

Sì so che si può specificare ma quindi quale dimensione dovrei mettere?
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 01-09-2004, 21:09   #4
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
E' la dimensione del messaggio che devi inviare, immagino. Nota che le strutture contenenti il messaggio, nel tuo caso, non hanno dimensione fissa.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 01-09-2004, 23:51   #5
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
Esattamente così! Il fatto è che il ricevente deve conoscere a priori la dimensione del messaggio, e il mio msg diventa dopo 4 invii di ben 1296 caratteri! Dovrei quindi avere un vettore di 1296 spazi? È forse opportuno gestire diversamente la struttura dati per il messaggio?
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 02-09-2004, 08:00   #6
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Il ricevente non deve necessariamente conoscere la dimensione del messaggio in quanto tale valore è restituito da msgrcv. Se il tuo buffer è troppo piccolo per contenere il messaggio, viene ritornato l'errore E2BIG e puoi riallocare un buffer più grande (ad es. il doppio del precedente).
Vedi man msgrcv.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 02-09-2004, 10:57   #7
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
mmm comincio a capire...
quindi ci sono due problemi di spazio uno della coda stessa (viene ritornato l'errore EAGAIN e posso ridimensionare la coda con msgctl aumentando il valore oltre MSGMNB che è quello predefinito dal sistema), e l'altro del msg (viene ritornato l'errore E2BIG ma posso ridimensionare il parametro msgsz e ripetere l'operazione di ricezione)

Teoricamente credo sia corretto, ora apro vim...

Grazie mille!
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 05-09-2004, 18:08   #8
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
Ciao, mi spiace ma non sono ancora giunto alla fine... sono riuscito a far funzionare lo scambio di messaggi utilizzando come struttura del msg questa:

typedef struct msgbuf {
long mtype; /* message type */
long sender; /* message sender */
char mtext[MSGSZ]; /* message text of length MSGSZ */
} message_buf


Però in questo modo il msg è fissato nella sua dimensione e vorrei dipendesse ad esempio da un parametro di ingresso da linea di comando. Penso allora di sostituire l'ulitmo campo con un puntatore a char:

char *mtext

allocando con malloc abbastanza memoria.

Lo scambio di messaggi dovrebbe avvenire perchè con ipcs vedo che la coda è vuota, ma andando a leggere nel buf di ricezione ci sono solo strani caratteri.

Grazie
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 05-09-2004, 23:48   #9
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
Una precisazione... il messaggio viene ricevuto perchè nel campo sender della struct riesco a leggere il dato corretto, ma non nel campo mtext.
opiu è offline   Rispondi citando il messaggio o parte di esso
Old 06-09-2004, 08:04   #10
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Io farei così:
Codice:
typedef struct msgbuf { 
 long mtype;
 long sender;
 char mtext[0];
 } message_buf 

(...)
struct msgbuf *alloca_messaggio(int msgsz) {
  struct msgbuf *ret;
  ret = malloc(sizeof(*ret)+msgsz);
  return ret;
}
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 06-09-2004, 11:48   #11
opiu
Member
 
L'Avatar di opiu
 
Iscritto dal: Apr 2001
Messaggi: 111
Grazie mille... funziona tutto alla perfezione ora
Ciao
opiu è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Gigabyte MO32U24 OLED: il 4K a 240Hz su un pannello OLED ideale per il gaming Gigabyte MO32U24 OLED: il 4K a 240Hz su un panne...
Recensione realme 16 5G: lo smartphone con Selfie Mirror ha una batteria da 6550mAh Recensione realme 16 5G: lo smartphone con Selfi...
Come rispettare tutte le nuove regole per i monopattini elettrici? La guida per non rischiare sanzioni Come rispettare tutte le nuove regole per i mono...
DLSS 4.5: con Dynamic Frame Generation e MFG 6X NVIDIA alza la posta DLSS 4.5: con Dynamic Frame Generation e MFG 6X ...
Plaud NotePin S, il registratore IA si fa indossabile (ma è facile da perdere) Plaud NotePin S, il registratore IA si fa indoss...
L'America si ribella ai datacenter: bloc...
'Artificial General Engineer': l'IA di J...
Il drone NASA Dragonfly, che voler&agrav...
Stop immediato a Fable 5 e Mythos 5: il ...
"Prime Day Amazon il 23-26 giugno": sì e...
Oggi 2 super MacBook Pro M5 e M5 Pro, 24...
Tineco Floor One Station S9 Artist: il s...
Raggiunte nuove altitudine e velocit&agr...
Apple Watch Series 11 GPS a 339€ su Amaz...
Come un MacBook, ma con la RTX 5070: MSI...
Paolo Zaccardi: "Smettere di assume...
Finalmente a buon prezzo 2 mini PC con R...
Samsung Galaxy Watch 7: uno crolla a 146...
NVIDIA pronta al 'piano B' per la Cina: ...
Xiaomi TV A Pro 55 a soli 366€: è...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 12:43.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v