Posts written by GILA75

view post Posted: 22/1/2020, 19:58 Perplessità processi (c,java,python, generico) - Informatica.
e si, sembra un po' macchinoso, ma come detto è un argomento davvero vasto.
I miei dubbi (dettati dall'ignoranza in merito) sono tanti.
Un'altro per esempio è se le pipes siano monouso o meno: se io ho un processo che comunica all'altro in più riprese
è fattibile con la stessa pipe ? Oppure cessa una volta scritti i dati ?
Da prove sommarie sembrerebbe non si possano riutilizzare...bho non sono sicuro... :wb:
Magari per implementare un rudimentale gioco del bruco, i processi non sono così fondamentali.
Si potrebbe fare tutto a polling (si dice così ? non ricordo più), ma durante le temporizzazioni, per esempio
il programma sarebbe sordo alla pressione dei tasti di movimento...insomma non sarebbe il massimo credo.
view post Posted: 21/1/2020, 17:51 Perplessità processi (c,java,python, generico) - Informatica.
Ecco, questo è un esempio ufficiale e non scritto da un dilettante come me. Sembra che anche qui si aprano e chiudano i "canali"
CODICE
#include <sys/types.h>
      #include <sys/wait.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <string.h>

      int
      main(int argc, char *argv[])
      {
          int pipefd[2];
          pid_t cpid;
          char buf;

          if (argc != 2) {
              fprintf(stderr, "Usage: %s <string>\n", argv[0]);
              exit(EXIT_FAILURE);
          }

          if (pipe(pipefd) == -1) {
              perror("pipe");
              exit(EXIT_FAILURE);
          }

          cpid = fork();
          if (cpid == -1) {
              perror("fork");
              exit(EXIT_FAILURE);
          }

          if (cpid == 0) {    /* Child reads from pipe */
              close(pipefd[1]);          /* Close unused write end */

              while (read(pipefd[0], &buf, 1) > 0)
                  write(STDOUT_FILENO, &buf, 1);

              write(STDOUT_FILENO, "\n", 1);
              close(pipefd[0]);
              _exit(EXIT_SUCCESS);

          } else {            /* Parent writes argv[1] to pipe */
              close(pipefd[0]);          /* Close unused read end */
              write(pipefd[1], argv[1], strlen(argv[1]));
              close(pipefd[1]);          /* Reader will see EOF */
              wait(NULL);                /* Wait for child */
              exit(EXIT_SUCCESS);
          }
      }
view post Posted: 18/1/2020, 12:42 Perplessità processi (c,java,python, generico) - Informatica.
CITAZIONE
Dunque, ok per il monodirezionale ma continuo a pensare che quelle close() siano errate... magari prova!

Vedo che sono citati i socket anche qua, e quindi torno a pensare che decisamente siano una soluzione migliore! Tra l'altro l'indirizzo 127.0.0.1 dovrebbe essere disponibile sempre anche se non c'è la scheda di rete, per quanto poi oggigiorno tutti hanno una scheda di rete.

Stavo però pensando anche... non dovresti "aspettare", specie in lettura, che i dati siano presenti? Il tuo codice "passa" attraverso le write (diciamo che questo è ok) e le read (e qua non so...) senza aspettare che i dati siano passati... qualcosa tipo un "check data ready"?


Be' il senso ce l'ha sempre :) per imparare!

dopo posto un programma trovato in rete, sembra usino close nello stesso modo.
Si, i socket penso siano meglio. Da quanto ho capito, le pipes, sono uno dei primi metodi e forse anche i più
rudimentali. Avevo fatto prove anche con i socket. Mi sono imbattuto nelle pipes, per puro diletto ed esercizio.

CITAZIONE
Stavo però pensando anche... non dovresti "aspettare", specie in lettura, che i dati siano presenti? Il tuo codice "passa" attraverso le write (diciamo che questo è ok) e le read (e qua non so...) senza aspettare che i dati siano passati... qualcosa tipo un "check data ready"?

allora, quando io scrivo il buffer write (se non erro di pochi kb), manda i dati alla read. Read appena riempie il buffer, blocca write che aspetta lo svuotamento...se dico giusto...
questo finchè la chiamata è atomica (inferiore al buffer). nel caso contrario le cose potrebbero essere diverse.
Come detto, i dettagli sono molti, e occorrono parecchie prove e studio.
Cosa che al 99% in Python& company, non ti devi preoccupare...ma è bello anche imparare.
Per esempio in set di python, vengono implementate le tabelle di hash, cosa che se non hai scritto in C
non sai nemmeno cosa sono, come sono gestite le collisioni: indirizzamento aperto ? Liste di trabocco ???
Insomma il C non è propriamente semplice
view post Posted: 18/1/2020, 11:54 Perplessità processi (c,java,python, generico) - Informatica.
Riporto la versione che non mi funziona, che usa una pipe sola:
CODICE
#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<sys/wait.h>
#include  <string.h>
#define READ 0
#define WRITE 1

// WAITPID: ASPETTA CHE UN PROCESSO SPECIFICO FINISCA
// POI GLI ALTRI SONO RACCOLTI WAIT
//*************************************************
// esempio di comunicazione padre figlio:
// il padre manda un array con pipe0
// il figlio la legge con pipe 0, lo elabora
// e la manda al padre con pipe1
// genn 2020


int main(int argc, char *argv[])
{
       int pid,x,i;
       int my_pipe_0[2];
       int prova[4]={100,2,3,4};
       int buff[4];
       int status;
// creo le pipes
       if (pipe(my_pipe_0)==-1)
       {
               puts("erroer");
               return -1;
       }

       
       
//********************************************
//                        filglio
//********************************************
       
       pid = fork();
       if ( pid == -1 )
       {
               printf ("Impossibile creare un nuovo processo\n");
               exit(1);
       }

       if ( pid == 0 )
       {
               int i;
               printf ("Sono il processo 0 figlio di %d, il mio PID è %d\n",getppid(), getpid());
               puts("leggo quello che mi manda il padre");
               close (my_pipe_0[WRITE]);// chiudo canale scrittura pipe0
               read(my_pipe_0[READ], buff, 4*sizeof(int)); //leggo quello che il padre manda
               close (my_pipe_0[READ]); // chiudo lettura pipe0
               for (i=0; i<4; i++)
               {
                       printf("child %d\n",buff[i]);
                       prova[i]=prova[i]*100;
               }
               
               close (my_pipe_0[READ]);// chiudo canale lettura pipe0
               write(my_pipe_0[WRITE], prova, 4*sizeof(int)); // scrivo con pipe0 al padre
               close (my_pipe_0[WRITE]); // chiudo canale scrittura pipe0
               puts("fine figlio");
               exit(0);
       }    

       
//************************************************************
//                        MAIN
//************************************************************
       if ( pid> 0 )
       {
               puts("sono nel main");
               close (my_pipe_0[READ]); //chiudo canale lettura pipe0
               write(my_pipe_0[WRITE], prova, 4*sizeof(int));//scrivo al figlio con pipe0
               close (my_pipe_0[WRITE]);// chiudo canale scrittura pipe0
               
//-------------------------------------------------------
               close (my_pipe_0[WRITE]); //chiudo canale scrittura pipe0
               read(my_pipe_0[READ], buff, 4*sizeof(int));//leggo cio che manda il figlio
               close (my_pipe_0[READ]);// chiudo canale lettura pipe0
               x=wait(&status);
               for (i=0 ;i<4 ;i++)
                       printf("dati elaborati mandati dal figlio: %d\n",buff[i]);
               printf ("Il processo  %d è terminato con status %d\n", x,status);
       
       }
       return 0;

}


e i 2 output:
CODICE
gila@gila-pc:~/Scrivania$ ./xx
sono nel main
Sono il processo 0 figlio di 3197, il mio PID è 3198
leggo quello che mi manda il padre
child 100
child 2
child 3
child 4
fine figlio
dati elaborati mandati dal figlio: 10000
dati elaborati mandati dal figlio: 200
dati elaborati mandati dal figlio: 300
dati elaborati mandati dal figlio: 400
Il processo  3198 è terminato con status 0
/**********************************************************************

sono nel main
Sono il processo 0 figlio di 3280, il mio PID è 3281
leggo quello che mi manda il padre
child 100
child 2
child 3
child 4
fine figlio
dati elaborati mandati dal figlio: 0
dati elaborati mandati dal figlio: 0
dati elaborati mandati dal figlio: 0
dati elaborati mandati dal figlio: 0
Il processo  3281 è terminato con status 0
gila@gila-pc:~/Scrivania$


il secondo output come si nota, perde i valori.
Comunque leggendo qui:
CITAZIONE
Nei sistemi operativi una pipe è uno degli strumenti disponibili per far comunicare tra loro dei processi. Le pipe, diversamente dai socket, offrono un canale di comunicazione monodirezionale, e quindi occorre impiegarne due per ottenere una comunicazione bidirezionale.

tratto da wikipedia, sembrerebbe proprio che ce ne vogliano 2.
Riguardo al discorso di aprire e chiudere i canali, anche li dovrebbe essere come dico...però...
Sto cercando di simulare una broken pipe, cioè un errore che dovrebbero dare canali aperti simultaneamente, ma non
mi riesce. Non so, forse bisogna tirare in ballo pure i segnali.
Insomma, è un argomento molto vasto.
A dire il vero (eterna domanda), mi domando se tutto ciò ha senso per un livello hobbistico...bho!!!
view post Posted: 17/1/2020, 20:52 Perplessità processi (c,java,python, generico) - Informatica.
CITAZIONE
Vediamo. Peccato non poter provare il tuo codice perché ho solo Windows...

e, si, mi sono avvicinato così per caso al mondo Unix, Ubuntu ecc, e a livello di sistema operativo mi trovo
un po' meglio, quindi mi sono fermato li.
Al massimo posto gli output che ottengo.
Come ultima cosa, poi domani posto il codice.
La mia impressione e che una pipe oltre essere mono direzionale, sia anche monouso. O almeno è questa la mia
perplessita'
pensavo che facendo:
padre( apro write e chiudo read)----->scrivo a figlio (chiudo write e apro read) (qui tutto ok)

quello che non funziona è questo (stessa pipe):
figlio (chiudo read, apro write)-----> scrivo a padre (chiudo write, apro read)
non va, se uso una seconda pipe si.
Allora la domanda è: una volta usata la pipe si "distrugge" ?
Qui è proprio questione di spulciare per bene la documentazione...
Intanto grazie Dario
view post Posted: 17/1/2020, 20:36 Perplessità processi (c,java,python, generico) - Informatica.
Domani ti posto la versione che a me sembra non funzionare. Usando cioè un pipe sola.
La chiusura dei canali non richiesti dovrebbe essere se mi sono documentato bene obbligatoria.
Se il figlio deve leggere, è raccomandato, se non tassativo (ripeto, se non erro) chiudere il canale di scrittura.
Domani, modifico il codice, e posto la versione che non mi funziona.
Intanto mi documento.
La mia idea, sarebbe quella di accoppiare processi con terminale "semigrafico" (ncurses).
Per esempio, il gioco del bruco: un processo, mi potrebbe leggere i tasti direzionali, un'altro la gestione
del bruco e via dicendo...sembra semplice, ma mica tanto.
Vedremo se mi riesce qualcosa di carino
view post Posted: 17/1/2020, 20:26 Perplessità processi (c,java,python, generico) - Informatica.
CITAZIONE
dice che vengono restituiti "descrittori entrambi usabili in lettura E scrittura" ...

Tu hai provato?

al momento non riesco a capire cosa intendi.
tu dici qui ?
CITAZIONE
A pipe can be explicitly created in Unix using the pipe system call. Two file descriptors are returned--fildes[0] and fildes[1], and they are both open for reading and writing. A read from fildes[0] accesses the data written to fildes[1] on a first-in-first-out (FIFO) basis and a read from fildes[1] accesses the data written to fildes[0] also on a FIFO basis.

nel momento della creazione, si hanno 2 descrittori : 0 per default lettura e 1 scrittura.
Se intendi questo, si, faccio in questo modo, ma il mio cruccio riguarda altro.
A dire il vero, sono molte cose che ancora non so.
Pipe, socket, segnali, è un argomento vastissimo
view post Posted: 17/1/2020, 19:36 Perplessità processi (c,java,python, generico) - Informatica.
ti posto il codice, è una cosa semplice.Appena riesco cerco di vedere il link che mi hai mandato.
Spero mantenga la formattazione, ma ne dubito :(

CODICE
#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<sys/wait.h>
#include  <string.h>
#define READ 0
#define WRITE 1

// WAITPID: ASPETTA CHE UN PROCESSO SPECIFICO FINISCA
// POI GLI ALTRI SONO RACCOLTI WAIT
//*************************************************
// esempio di comunicazione padre figlio:
// il padre manda un array con pipe0
// il figlio la legge con pipe 0, la elabora
// e la manda al padre con pipe1
// genn 2020


int main(int argc, char *argv[])
{
       int pid,x,i;
       int my_pipe_0[2];
       int my_pipe_1[2];
       int prova[4]={100,2,3,4};
       int buff[4];
       int status;
// creo le pipes
       if (pipe(my_pipe_0)==-1)
       {
               puts("errore");
               return -1;
       }

       if (pipe(my_pipe_1)==-1)
       {
               puts("errore");
               return -1;
       }
       
//********************************************
//                        figlio
//********************************************
       
       pid = fork();
       if ( pid == -1 )
       {
               printf ("Impossibile creare un nuovo processo\n");
               exit(1);
       }

       if ( pid == 0 )
       {
               int i;
               printf ("Sono il processo 0 figlio di %d, il mio PID è %d\n",getppid(), getpid());
               puts("leggo quello che mi manda il padre");
               close (my_pipe_0[WRITE]);// chiudo canale scrittura pipe0
               read(my_pipe_0[READ], buff, 4*sizeof(int)); //leggo quello che il padre manda
               close (my_pipe_0[READ]); // chiudo lettura pipe0
               for (i=0; i<4; i++)
               {
                       printf("child %d\n",buff[i]);
                       prova[i]=prova[i]*100;
               }

               close (my_pipe_1[READ]);// chiudo canale lettura pipe1
               write(my_pipe_1[WRITE], prova, 4*sizeof(int)); // scrivo con pipe1 al padre
               close (my_pipe_1[WRITE]); // chiudo canale scrittura pipe1
               puts("fine figlio");
               exit(0);
       }    

       
//************************************************************
//                        MAIN
//************************************************************
       if ( pid> 0 )
       {
               puts("sono nel main");
               close (my_pipe_0[READ]); //chiudo canale lettura pipe0
               write(my_pipe_0[WRITE], prova, 4*sizeof(int));//scrivo al figlio con pipe0
               close (my_pipe_0[WRITE]);// chiudo canale scrittura pipe0
               
//-------------------------------------------------------
               close (my_pipe_1[WRITE]); //chiudo canale scrittura pipe1
               read(my_pipe_1[READ], buff, 4*sizeof(int));//leggo cio che manda il figlio
               close (my_pipe_1[READ]);// chiudo canale lettura pipe1
               x=wait(&status);
               for (i=0 ;i<4 ;i++)
                       printf("BUFF %d\n",buff[i]);
               printf (" Il processo  %d è terminato con status %d\n", x,status);
       
       }
       return 0;

}
view post Posted: 17/1/2020, 18:04 Perplessità processi (c,java,python, generico) - Informatica.
Ciao Dario...bhè, diciamo che a tempo perso cerco di rispolverare argomenti un po' ostici del C:
processi, segnali, socket ecc...tutta roba che se fatta bene, ti porta via molto tempo e studio.
Le pipes come saprai, fanno comunicare 2 processi, con la clausola che devono avere un avo in comune.
Sono half-duplex, cioè mono direzionali...e qui viene la mia perplessità.
Supponiamo l'esempio (tralascia l'inutilità pratica).
Ho un padre e un figlio (con realtiva fork() in ambiente unix), il padre manda con una pipe al figlio un array di
int supponiamo, quindi uso una pipe che scrive al figlio.
Quindi nel padre chiudo il canale lettura, abilito quello di scrittura, inversa cosa nel figlio.
Ok, il figlio legge, elabora l'array e lo rispedisce al padre che lo stampa.
In un primo momento credevo che potessi usare una sola pipe, invece me ne servono 2.
La prima scrive al figlio e nel figlio legge, la seconda scrive al padre e il padre legge.
Non capisco se è giusto. Io intendevo (al 99% in modo errato) che fossero unidirezionali nel senso che mente scrivi
il canale di lettura è bloccato e viceversa, non che non le puoi riutilizzare.
Usando 2 pipes tutto funziona, una no.
Posso postare l'esempio nel caso, è per ambiente unix, ma credo che il concetto a parte la fork, la creazione della pipe
e il wait nel padre, tutto sia lo stesso anche in windows.
Sto facendo prove perchè mi piacerebbe abbinare i processi alla libreria ncurses, per rudimentali giochi tipo il bruco
tetrix ecc.
view post Posted: 16/1/2020, 20:21 Perplessità processi (c,java,python, generico) - Informatica.
Sempre restando in tema di processi, provo a chiedere, è più cosa da computer che da mirco...va bhè.
In C qualcuno di voi sa la teoria delle pipes ? comunicazione tra processi in pratica.
Ho delle perplessità...
view post Posted: 12/1/2020, 20:31 Toni DTMF - Informatica.
Se proprio vogliamo dirla tutta, a mio modo di vedere, i nuovi linguaggi, essendo più semplici, invogliano ancora di più
i cialtroni.
Con poche pagine di manuale, fai quello che magari in assembler dovevi romperti la testa, facendoti credere (erroneamente) di esser un buon programmatore...cosa più lontana dal vero.
Siamo ampiamente OT sui toni dtmf...va bhè pazienza.
Come dicevo, i linguaggi ad alto livello, paradossalmente sono ancora più insidiosi. Faccio un esempio.
tempo fa scrivevo il crivello di Eratostene o il problema di Giuseppe Flavio (non ricordo) in python.
ebbene, con 2 righe, avendo a disposizione oggetti precostituiti molto potenti, ho risolto.
Risultato ? Un programma da schifo!!!
Avendo un piccolo bagaglio amatoriale In C, ho riscritto adottando un'altra logica e allontanandomi dalle lusinghe di pochi sforzi del Python, ed è migliorato di parecchi fattori.
Tutto questo per dire, che la cialtroneria potrebbe addirittura aumentare, in virtù appunto delle facili promesse di alcuni linguaggi. Poi ovvio a certi livelli penso che ti facciano "il culo a strisce" se solo usi una variabile non necessaria, non facciamo tutto di un erba un fascio dai...
view post Posted: 12/1/2020, 18:22 variare tensione trasformatore - Elettronica generale
CITAZIONE
mi chiedo perche a tutti le cose vengono alla prima e a me mai...

Che film hai visto Doc ?? Non so, sarai andato nel futuro e avrai conosciuto cervelloni!!!
Ma che stai dicendo dai ? Io il minithermin mesi e mesi all'oscilloscopio, bobina di tesla un sacco
di prove....senza calcolare con i pic: giorni passati a scovare un bug con sto cacchio di mplab.
A tutti vengono alla prima non ci credo. Forse postano quando tutto è fatto... non so

EDIT:
ma il pirografo è la penna ad incisione elettrica ? in definitiva?
Io per avere delle basse uscite in volts, e molti ampere in uscita avevo usato un trafo del micronde.
Rimosso il secondario e fatto qualche spira di filo, ma assorbiva troppo.
Non ricordo se parlavo qui, c'erano anche dei lamierini nel trafo che limitavano la potenza, ma non ricordo bene.

Edited by GILA75 - 12/1/2020, 18:30
view post Posted: 12/1/2020, 18:14 Toni DTMF - Informatica.
CITAZIONE
Cioè, è bella l'astrazione ed è lecito pagare un costo in termini di prestazioni pur di lavorare più facilmente e "astraendosi": ma certe cose che si vedono in giro sono ORRIBILI, ossia sprecone, malfatte ecc

Essendo voi (tu, Robo,Law ecc...) dentro a queste cose, posso solo credervi, e immagino.
Forse anni addietro c'era più rigore e anche passione per l'elettronica\informatica.
Non so si vedono laureandi su certi forum, che non ne vengono fuori da printf() ...bho.
Io credo che per fare certi lavori, oltre che esserci tagliato, ti devono appassionare, se no, lascia perdere.
Chi ha il pane non ha i denti e viceversa...potessi io avere lavori del genere mannaggia!!!!
view post Posted: 12/1/2020, 17:56 Bobina BAC conica - Sezione di Paperoga
Si, mia nonna diceva: il gioco è bello finchè dura poco. Un po' ci sta, ma dopo un po' suona di presa per i fondelli.
view post Posted: 12/1/2020, 17:43 Toni DTMF - Informatica.
CITAZIONE
Bello. Si, ma la cosa peggiore è che per eseguire una istruzione a livello macchina tipo load A, in 8080 o z80 è il semplice codide hex 3A. La metti in rom ed il processore fa quello in qualche decina di nanosecondi. "NANOSECONDI" e basta, senza avere compilatori, assemblatori collocatori, librerie e passaggi che ti portano via qualche ora a te qualche giga di ram, qualche giga di disco e alla fine tutto va in malora. La "malora" è la cosa peggiore di tutto il discorso. ;)

è un argomento complesso, e io da semplice operaio non posso capire molto, ma cerco a mio modo, giusto
per il piacere di conversare, di dire la mia:
Credo che sia errato vedere la nuove tecnologie come lente, macchinose, che per fare le cose che si facevano 30 anni fa
, ora si debba fare un giro pindarico infinito.
Non sono del ramo, ma penso che i processori, o i processi dove è richiesta velocità pura, siano ancora molto spartani,
che il tutto venga prevalentemente affidato alla parte hardware no?
Del resto quello che abbiamo oggi, non so, penso a grafiche di videogames paurose, non lo avevamo 10 anni fa.
Quindi penso che i frutti ci siano eccome.
Secondo me, è che in nuovi linguaggi, le nuove tecnologie, cercano di astrarre a un livello sempre più alto, sempre più vicino all'uomo. E tutto ciò ha un prezzo: molto più semplice, ma molto più lento.
Se vogliamo guardare, si è inventato l'assembly, per rendere più umano 1000111100 (binario), che però è
più lento, il C per ridurre i casini dell'assembly, il python, ruby ecc...per ridurre il C.
Tutto però apparentemente è più lento. Un programma Python può girare 20 o 30 volte più lento dell' equivalente C.
Un male ? Non sempre, si può ricorrere al C se serve, ma la la lentezza è ampiamente ripagata da uno sviluppo molto
più veloce , meno errori, meno sintassi, più tempo da dedicare alla logica piuttosto che alle grane del linguaggio,
meno righe di codice ecc...

In python (ma lo stesso vale c---->assembly), puoi fare strutture dati che in C vai alla neuro, in poco tempo.
è vero, nasconde molte cose, che sarebbe bene sapere (puntatori, malloc, free...ecc non saprai mai cosa sono)
Ma l'astrazione è talmente alta ed efficiente che a mio avviso merita il prezzo.
A pensarci bene l'uomo cerca di astrarre tutto: i numeri, noi li abbiamo immaginati così:1,2,3, è una nostra rappresentazione , ma chi ci dice che siano davvero così? Magari sono un qualcosa che noi non possiamo immaginare, e magari manipolati nella loro natura sconosciuta sarebbe più veloce fare i calcoli (stesso di 100001111 vs Assembly)
ma noi ce ne freghiamo: 'paghiamo un piccolo prezzo a patto della semplicità e chiarezza.
Bhò... forse vado fuori tema.... :D
1581 replies since 4/11/2007