C: Περίεργη συμπεριφορά της free()?

[geomagas]

Μπορείς να μου εξηγήσεις πώς γίνεται αυτό το πρόγραμμα να δίνει την έξοδο που δίνει χωρίς να μηδενίζει τη μνήμη manually η calloc?

 

Φυσικά και όχι.

 

Κατσε, κατσε.

 

Που ξέρεις ότι το αποτέλεσμα της δεύτερης calloc δεν αφορά διαφορετικό physical page από αυτό της πρώτης, το οποίο είναι ήδη wiped από το λειτουργικό ages ago?

 

Το ότι σου δίνει την ίδια διεύθυνση στο virtual memory space δεν σημαίνει ότι βλέπεις την ίδια φυσική μνήμη που έβλεπες με το πρώτο calloc. Έτσι δεν είναι;

 

(Βέβαια, σε αυτή την περίπτωση, η απορία μου είναι αν και η malloc δουλεύει έτσι, κι αν όχι γιατί, αλλά μην πλατιάζουμε κι άλλο...)

[defacer]

Που ξέρεις ότι το αποτέλεσμα της δεύτερης calloc δεν αφορά διαφορετικό physical page από αυτό της πρώτης, το οποίο είναι ήδη wiped από το λειτουργικό ages ago?

 

Το ότι σου δίνει την ίδια διεύθυνση στο virtual memory space δεν σημαίνει ότι βλέπεις την ίδια φυσική μνήμη που έβλεπες με το πρώτο calloc. Έτσι δεν είναι;

 

Δεν το ξέρω αν δεν πάω να δω ακριβώς τι κάνει το c runtime, αλλά το "ξέρω" και χωρίς να δω επειδή για να γίνει αυτό που λες θα έπρεπε ανάμεσα στη free και τη δεύτερη calloc να έχει μεσολαβήσει κατ' ελάχιστον dealloc και ξανά alloc virtual μνήμης από το λειτουργικό.

 

Αυτό το πράγμα δε γίνεται από μόνο του, πρέπει το runtime να το κάνει επίτηδες. Εδώ τώρα μιλάμε για τη C στην οποία θεωρείται νορμάλ να παίρνεις στα χέρια σου μνήμη με άγνωστα τι προηγούμενα σκουπίδια μέσα επειδή "δεν κάνω πράγματα που δεν είναι τελείως απαραίτητα για να μη πληρώνεις runtime costs εκεί που δε χρειάζεται".

 

Δώσε μου λοιπόν μια οποιαδήποτε λογική εξήγηση γιατί το runtime να έχει κάνει virtual free και ξανά virtual alloc στο ενδιάμεσο. Ελπίζω να συμφωνούμε πως αν δε μπορείς να το κάνεις τότε είτε δε συνέβη, είτε ο implementor της συγκεκριμένης libc ζει σε άλλο πλανήτη.

[geomagas]

Ενα-ενα.
 

Δεν το ξέρω αν δεν πάω να δω ακριβώς τι κάνει το c runtime, αλλά το "ξέρω" και χωρίς να δω επειδή για να γίνει αυτό που λες θα έπρεπε ανάμεσα στη free και τη δεύτερη calloc να έχει μεσολαβήσει κατ' ελάχιστον dealloc και ξανά alloc virtual μνήμης από το λειτουργικό.

 

Όχι, γιατί το λες αυτό; Δεν καταλαβαίνω γιατί θα πρέπει.

 

- Κάνεις το πρώτο allocation. Τo Λ/Σ σου δίνει μία διεύθυνση virt1 που αντιστοιχεί στη φυσική διεύθυνση phys1.

- Κάνεις free και αμέσως μετά alloc. Φυσικά το Λ/Σ θα σου δώσει την ίδια virtual διεύθυνση (virt1), αφού αυτή είναι η αμέσως επόμενη διαθέσιμη. Όμως, στον VMT μπορεί πολύ άνετα virt1 --> phys2 πλέον (hint: δεν ξέρεις τι έχουν κάνει άλλα processes στο μεταξύ). Μάλιστα, αυτός είναι ο κανόνας κι όχι η εξαίρεση.

 

Δεν βλέπω το λόγο να πρέπει να συντρέχουν άλλες προϋποθέσεις για να ισχύει αυτό.

[defacer]

- Κάνεις το πρώτο allocation. Τo Λ/Σ σου δίνει μία διεύθυνση virt1 που αντιστοιχεί στη φυσική διεύθυνση phys1.

Να το πω σωστότερα για να συνεννοούμαστε.

 

Το OS σου δίνει μια virtual address (αυτή που τυπώνει το πρόγραμμα που έδωσα) η οποία είναι mapped σε κάποια physical memory address. Δεν ξέρεις σε ποιά physical memory address και ποτέ δε μπορείς να μάθεις (that's the whole point of having virtual memory!). Επομένως από την οπτική του προγράμματος, μόνο μία address υπάρχει: η virtual.

 

Εννοείται ότι αν για οποιοδήποτε λόγο το λειτουργικό αποφασίσει να αλλάξει το mapping της virtual address που σου έχει δώσει και να το βάλει αλλού στη RAM, αυτό θα πρέπει να γίνει με τέτοιο τρόπο ώστε από την οπτική του προγράμματος να μην έχει αλλάξει απολύτως τίποτα. Και ξαναλέω, το πρόγραμμα δεν έχει και δε μπορεί να έχει τρόπο να καταλάβει ότι έγινε κάτι τέτοιο.

 

- Κάνεις free και αμέσως μετά alloc. Φυσικά το Λ/Σ θα σου δώσει την ίδια virtual διεύθυνση (virt1)

Εδώ αν καταλαβαίνω καλά ήδη έχεις κάνει τεράστιο λάθος γιατί εξισώνεις τη free και την -alloc του C runtime με τις virtual free/alloc του OS. Είναι δύο τελείως διαφορετικά πράγματα, και εννοείται πως ο allocator του runtime προσπαθεί να εξυπηρετήσει όσο το δυνατόν καλύτερα. Το να ζητάει καινούριο allocation από το OS για κάθε allocation που ζητάει το πρόγραμμα είναι wasteful σε βαθμό που δεν περιγράφεται, τόσο από άποψη χρόνου (πρέπει να κάνει context switch για να μπει σε kernel mode προκειμένου να γίνει το virtual allocation) όσο φυσικά και από άποψη χώρου (εσύ μπορεί να ζητάς 1 byte, ενώ το virtual page size του λειτουργικού είναι Ν).

 

Αν δεν πιστεύεις εμένα μπορείς να το ψάξεις μόνος σου, σχετικά βιβλία υπάρχουν πολλά, εγώ απλά να σου δώσω αυτό το σύντομο google result:

 

the userspace library manages memory allocations within this limit, and only when needed ask the kernel to increase it.

Επομένως όχι, το OS δε θα σου δώσει τίποτα στο δεύτερο alloc γιατί ήδη από το πρώτο alloc το C runtime έχει πάρει ένα αρκετά μεγάλο κομμάτι μνήμης το οποίο μέχρι να εξαντληθεί θα το διαχειρίζεται εσωτερικά. Το σύνολο αυτών των κομματιών μνήμης είναι που λέμε στην καθομιλουμένη "heap", και προφανώς αν το heap τύγχανε διαχείρισης από το OS τότε κάποιο πρόγραμμα δε θα είχε ποτέ τη δυνατότητα να το κάνει corrupt οπότε πράγματα όπως αυτό δε θα υπήρχαν.

 

αφού αυτή είναι η αμέσως επόμενη διαθέσιμη.

Αυτό το παρουσιάζεις σα να είναι guaranteed αλλά κάθε άλλο παρά guaranteed είναι. Μιλώντας πάντα για την περίπτωση όπου έχεις προκαλέσει virtual allocation (γιατί διαφορετικά όπως είπα παραπάνω μιλάμε για πράγματα που δε συμβαίνουν) ο πολύ απλός λόγος είναι πως δεν ξέρεις ποιό μηχανισμό θα χρησιμοποιήσει η malloc για να πάρει τη μνήμη που ζητάς.

 

Σε linux θα χρησιμοποιήσει είτε το system call brk() είτε τη mmap(), από τις οποίες η δεύτερη δεν παρέχει εγγυήσεις.

 

Σε windows θα χρησιμοποιήσει τη VirtualAlloc(), η οποία δεν παρέχει εγγυήσεις.

 

Όμως, στον VMT μπορεί πολύ άνετα virt1 --> phys2 πλέον (hint: δεν ξέρεις τι έχουν κάνει άλλα processes στο μεταξύ). Μάλιστα, αυτός είναι ο κανόνας κι όχι η εξαίρεση.

Είπα ήδη νωρίτερα ότι αν το ζεύγος free/alloc δεν έχει προκαλέσει καινούριο virtual page allocation αυτό που λες ακόμα και αν συμβαίνει δεν παίζει απολύτως κανένα ρόλο (αν το λειτουργικό αποφασίσει να πάει τα περιεχόμενα της μνήμης βόλτα παρόλα αυτά θα πρέπει να το κάνει με τρόπο που να με σου τραβάει το χαλί κάτω απ' τα πόδια).

 

Ακόμα και αν έχει προκληθεί καινούριο virtual page allocation στο ενδιάμεσο (που είναι σίγουρα η εξαίρεση και όχι ο κανόνας, μιας και αυτό δεν εξαρτάται καθόλου από τα άλλα processes) τότε και πάλι τα περιεχόμενα της μνήμης που θα πάρεις εξαρτώνται καθαρά από το λειτουργικό -- επομένως δε μπορείς να υποθέτεις πράγματα γι' αυτά.

 

Τέλος, και πραγματικά δεν καταλαβαίνω για ποιό λόγο χρειάζεται να το πω αυτό, αν η calloc ήταν "δωρεάν" τότε πώς εξηγείται το ότι η malloc είναι δυνατόν (to put it mildly) να επιστρέψει μνήμη που έχει μέσα σκουπίδια;

 

PS: Αν θέλεις να δεις τι κάνει και τι δεν κάνει ένας υψηλής ποιότητας generic allocator, δες τη jemalloc.

 

 

 

void *
base_calloc(size_t number, size_t size)
{
    void *ret = base_alloc(number * size);

    if (ret != NULL)
        memset(ret, 0, number * size);

    return (ret);
}

 

 

[imitheos]

Άσχετα από το πώς παίρνει η calloc τη μνήμη από το λειτουργικό, στη γενική περίπτωση θα σου επιστρέψει μνήμη την οποία μπορεί να έχεις ξαναχρησιμοποιήσει στο παρελθόν με προηγούμενη -alloc και την έχεις επιστρέψει με free. Σ' αυτή την περίπτωση η μνήμη θα έχει τα περιεχόμενα που άφησες την προηγούμενη φορά, οπότε η calloc δε μπορεί να κάνει οτιδήποτε διαφορετικό πέρα από το να τη μηδενίσει manually. Και φυσικά κανένας C allocator που είναι στα καλά του δεν πρόκειται να κρατάει σημειώσεις αν το τάδε τμήμα το έχεις ξαναχρησιμοποιήσει στο παρελθόν για προφανείς λόγους.

Κανονικά ναι για μικρά τμήματα θα σου δώσει ένα ξαναχρησιμοποιημένο οπότε η calloc θα πρέπει να το μηδενίσει χειροκίνητα. Πρακτικά όμως ο θεός και η ψυχή του.

 

Στα Windows πάντως, δυνητικά μια υλοποίηση της calloc θα μπορούσε να εκμεταλλευτεί τις συναρτήσεις του διαχειριστή μνήμη που προσφέρει το ΛΣ ώστε να λάβει άμεσα από αυτόν (δίχως ανάγκη να κάνει η ίδια οτιδήποτε περαιτέρω) ένα zeroed memory block.

Επίσης, αν χρειαστεί να προκαλέσει νέο page, εκεί όντως αργεί πάρα πολύ συγκριτικά με την malloc, αλλά το κάνει μια μόνο φορά και μετά τραβάει απευθείας από την page (προφανώς μέχρι να χρειαστεί να προκαλέσει νέο page).

@DirectX: Για Windows δεν ξέρω αλλά αυτό που περιγράφεις είναι η συνήθης λειτουργία.

 

@migf1: Δεν είναι απαραίτητο ότι θα αργεί και μάλιστα πάρα πολύ λόγω της λειτουργίας που περιέγραψε ο DirectX. Σε πολλά λειτουργικά (ή πολλές υλοποιήσεις vm αν θέλεις) υπάρχει ένα "thread" το οποίο δουλεύει στο παρασκήνιο συνεχώς (συνεχώς = όσο του επιτρέπει το load του μηχανήματος ώστε να μην εμποδίζονται οι κανονικές διεργασίες) και μηδενίζει σελίδες. Έτσι όταν ζητήσει η calloc (ή και η malloc) μνήμη θα πάρει κατευθείαν από αυτή τη περιοχή με τις μηδενισμένες σελίδες και δεν θα αργήσει καθόλου.

 

Σε vm που υποστηρίζουν overcommit (όπως στο linux με τη μανίσια λειτουργία του) αυτό πάει ακόμη παραπέρα. Δεν δίνονται καν σελίδες. Αν ζητήσεις 50 σελίδες (των 4096K), τότε όλες δείχνουν σε μία σελίδα η οποία είναι μαρκαρισμένη από τον πυρήνα ως read-only. Όταν πας να γράψεις σε κάποια από αυτές τις 50 σελίδες, τότε βαράει signal επειδή προσπάθησες να γράψει σε read-only περιοχή, το βλέπει ο αντίστοιχος handler του vm, και τότε και μόνο τότε σου δίνει κάποια πραγματική σελίδα.

 

Μπορείς να μου εξηγήσεις πώς γίνεται αυτό το πρόγραμμα να δίνει την έξοδο που δίνει χωρίς να μηδενίζει τη μνήμη manually η calloc?

 

Φυσικά και όχι.

 

int main(void) {                                                                
        char* p = malloc(1);                                                    
        *p = 42;                                                                
        printf("Memory malloced at %p: %d\n", p, *p);                           
        free(p);                                                                
                                                                                
        p = malloc(1);                                                          
        printf("Memory malloced at %p: %d\n", p, *p);                           
        return 0;                                                               
}
Έξοδος:
Memory malloced at 0x84a6008: 42
Memory malloced at 0x84a6008: 0

Ακόμη και με τη malloc, σε ένα σύγχρονο σύστημα δεν είναι σίγουρο τι θα γίνει. Μπορεί να σου δίνει άλλο physical page όπως είπε ο geomagas (όχι και τόσο πιθανό), μπορεί το malloc να αποφάσισε για το χ-ψ λόγο να σου δώσει άλλη περιοχή από αυτές που έχει κρατημένες, μπορεί να είναι αναγκασμένο να το μηδενίσει επειδή είναι ενεργοποιημένη κάποια επιλογή του πυρήνα για λόγους ασφαλείας, μπορεί 1002 πράγματα.

[defacer]

Ακόμη και με τη malloc, σε ένα σύγχρονο σύστημα δεν είναι σίγουρο τι θα γίνει. Μπορεί να σου δίνει άλλο physical page όπως είπε ο geomagas (όχι και τόσο πιθανό), μπορεί το malloc να αποφάσισε για το χ-ψ λόγο να σου δώσει άλλη περιοχή από αυτές που έχει κρατημένες, μπορεί να είναι αναγκασμένο να το μηδενίσει επειδή είναι ενεργοποιημένη κάποια επιλογή του πυρήνα για λόγους ασφαλείας, μπορεί 1002 πράγματα.

 

Σ' αυτό έχεις βέβαια δίκιο. Heck θα μπορούσε απλά το συγκεκριμένο πρόγραμμα να έχει γίνει compiled με optimizations (δεν είδαμε τα flags εξάλλου) και ο compiler να ήξερε ότι το write στον p δεν έχει observable side effect και απλά να μην το έβαζε καν μέσα στο πρόγραμμα.

 

Το θέμα είναι πως εγώ αν ήμουν στην απέναντι πλευρά για κάθε τέτοια ένσταση που μπορώ να σκεφτώ θα δοκίμαζα να αποδείξω ότι ισχύει. Αν τα κατάφερνα θα έλεγα ορίστε η απόδειξη ότι δεν είναι όπως τα λες. Αν δεν τα κατάφερνα θα έλεγα ότι δοκίμασα όλα αυτά τα πράγματα και παρόλο που δε μπορούμε να είμαστε 100% σίγουροι φαίνεται πως έχεις δίκιο, τουλάχιστον μέχρι εκεί που με παίρνει να αποφανθώ. Αλλά πού τέτοια μεγαλεία.

 

Anyway. Από τη δική μου την πλευρά ακόμα κι αν εγώ προσωπικά λέω μόνο βλακείες μετά τη jemalloc θεωρώ ότι το θέμα έχει κλείσει, τα πολλά τα πάρε δώσε καταντούν βαρετά κάποια στιγμή.

[migf1]

Όλα αυτά επειδή ο defacer as usual νομίζει πως τα ξέρει όλα, και αφετέρου επειδή θεωρεί πως εγώ δεν ξέρω τίποτα. Και απαξιεί μάλιστα να ψάξει μόνος του (λες και είμαστε υποχρεωμένοι να του κάνουμε φροντιστήριο).

 

Thumbs up στον ημίθεο, αν κι αυτό που γράφεις για το background thread, δεν το έχω συναντήσει... το έχω διαβάσει κι εγώ, αλλά δεν το έχω συναντήσει.

 

Επειδή ο χρόνος μου είναι περιορισμένος σήμερα, και δεν είμαι για να παίζω για μια ακόμα φορά τις κουμπάρες με τον defacer, σας βρήκα μερικά links στο πολύ πρόχειρο (εσύ defacer μην τα διαβάσεις, τα ξέρεις ήδη άλλωστε):

 

1. http://willnewton.name/uncategorized/calloc-versus-malloc-and-memset/

2. http://blogs.fau.de/hager/archives/825

3. https://developer.apple.com/library/mac/documentation/performance/conceptual/managingmemory/articles/MemoryAlloc.html

 

Το 3ο είναι μεγάλο, αλλά εξηγεί τα iOS/OSX internals (btw στο linux για μεγάλα chunks συνήθως καλούν mmap με MAP_ANONYMOUS για να πάρουν την zeroed page από το λειτουργικό). Στο λινκ αυτό έχει ενδιαφέρον πως ακόμα και για την malloc, για μεγάλα chunks χρησιμοποιούν παραπλήσια (αν όχι την ίδια) τεχνική με την calloc, επιστρέφοντας δηλαδή μηδενισμένη μνήμη (αν το 'πιασα καλά γιατί το είδα πολύ επί τροχάδην -έχω λίγη παραπάνω δουλίτσα σήμερα-... section: Memory Allocation Techniques -> Allocating Large Memory Blocks using Malloc)

 

ΥΓ. Επειδή δεν πρόκειται να ξανα-σχοληθώ για το συγκεκριμένο με οποιοδήποτε ποστ του defacer, απλώς να υπενθυμίσω πως έχω γράψει εξαρχής πως όλα αυτά είναι implementation dependant.

[defacer]

Αν μετά από όλα αυτά που είπαμε δε μπορείς να καταλάβεις ότι αυτά τα πράγματα ισχύουν μόνο για τη σπάνια περίπτωση όπου η calloc ικανοποιεί το αίτημά σου κάνοντας απευθείας virtual allocation από το λειτουργικό, κάτι το οποίο έχει μαλλιάσει η γλώσσα μου να λέω ότι κάθε άλλο παρά σίγουρο είναι, I feel sorry for you.

 

Ειδικά το τρίτο link λέει βασικά ακριβώς το αντίθετο απ' αυτό που υποστηρίζεις (και ίσως λογικό μιας και αναφέρεται σε Mac OS αν και δεν ξέρω): ότι η calloc είναι καλύτερη από malloc + memset γιατί μπορεί να μη χρειαστεί το memset. Αν ζητήσεις 10 bytes και αυτά ικανοποιηθούν από 17 pages των 4ΚΒ έκαστη, δε θα κάτσει η calloc να μηδενίσει και τις επόμενες 16 pages που κρατάει για καβάτζα (σε επίπεδο VM είναι allocated αλλά όχι committed, αυτό που λέει "mapped to physical memory").

[imitheos]

Στο λινκ αυτό έχει ενδιαφέρον πως ακόμα και για την malloc, για μεγάλα chunks χρησιμοποιούν παραπλήσια (αν όχι την ίδια) τεχνική με την calloc, επιστρέφοντας δηλαδή μηδενισμένη μνήμη

Είναι αυτό που εξήγησε πριν ο defacer για c runtime VS os. Όταν ζητήσεις μνήμη που ο allocator δεν μπορεί να σου προσφέρει θα αναγκαστεί να ζητήσει με *brk / mmap (ή κάτι αντίστοιχο σε win) από το λειτουργικό.

 

Ανεξάρτητα αν έχεις "ζητήσει" μηδενισμένη μνήμη με την calloc ή όχι, αυτή η μνήμη που θα σου δώσει θα πρέπει να είναι σβησμένη (όχι απαραίτητα με μηδενικά) γιατί αλλιώς θα υπήρχαν τεράστια κενά. Φαντάσου εκείνη η μνήμη να είχε κάποιο RSA κλειδί ή ποιος ξέρει τι και να το διάβαζες εσύ.

[migf1]

...

Ανεξάρτητα αν έχεις "ζητήσει" μηδενισμένη μνήμη με την calloc ή όχι, αυτή η μνήμη που θα σου δώσει θα πρέπει να είναι σβησμένη (όχι απαραίτητα με μηδενικά) γιατί αλλιώς θα υπήρχαν τεράστια κενά. Φαντάσου εκείνη η μνήμη να είχε κάποιο RSA κλειδί ή ποιος ξέρει τι και να το διάβαζες εσύ.

Σωστό (σόρι, όπως έγραψα και παραπάνω δεν έχω τον νου μου στο thread σήμερα, λόγω δουλειάς). Εν κατακλείδι, για να πάω να συνεχίσω, η calloc() δεν είναι κατά ανάγκη πιο αργή από την malloc(). Ανάλογα το implementation κι ανάλογα τι κάνουμε στον κώδικά μας (δεν θεωρώ δηλαδή πως στη γενική περίπτωση αξίζει να ασχολούμαστε με speed diffs μεταξύ τους).

[geomagas]

Να το πω σωστότερα για να συνεννοούμαστε.

 

Εδώ αν καταλαβαίνω καλά ήδη έχεις κάνει τεράστιο λάθος γιατί εξισώνεις...

 

Αν δεν πιστεύεις εμένα μπορείς να το ψάξεις μόνος σου...

 

Αυτό το παρουσιάζεις σα να είναι guaranteed...

 

Τέλος, και πραγματικά δεν καταλαβαίνω για ποιό λόγο χρειάζεται να το πω αυτό, αν η calloc ήταν "δωρεάν" τότε πώς εξηγείται το ότι η malloc είναι δυνατόν (to put it mildly) να επιστρέψει μνήμη που έχει μέσα σκουπίδια;

 

Ειλικρινά, γιατί το κάνεις αυτό;

[defacer]

Ειλικρινά, γιατί το κάνεις αυτό;

 

Δεν είμαι σίγουρος τι ακριβώς έχεις υπόψη. Αν θέλεις μπορούμε να το συζητήσουμε με ΠΜ.

[παπι]

Δεν είμαι σίγουρος τι ακριβώς έχεις υπόψη. Αν θέλεις μπορούμε να το συζητήσουμε με ΠΜ.

 

Δε λεω, σωστη η επιχειρηματολογια σου, αλλα ολο αυτο το κολλημα σε απλα πραματα... Ημαρτον.

[geomagas]

Δεν είμαι σίγουρος τι ακριβώς έχεις υπόψη. Αν θέλεις μπορούμε να το συζητήσουμε με ΠΜ.

 

Σε περίπτωση που πράγματι δεν κατάλαβες (που πολύ αμφιβάλλω), σπάω το κεφάλι μου να καταλάβω γιατί πάντα θα πρέπει να συμπεριφέρεσαι τόσο απαξιωτικά και ελιτίστικα στο συνομιλητή σου.

 

Δεδομένου ότι:

  (1) Όλοι μπορούμε να φερθούμε έτσι, απλά οι υπόλοιποι το αποφεύγουμε από επιλογή κι όχι από αδυναμία, και

  (2) Ένας άνθρωπος της δικής σου νοημοσύνης αποκλείεται να το κάνει "παρορμητικά" και "κατά λάθος"

...συμπεραίνω εύλογα ότι το κάνεις συνειδητά και από επιλογή.

 

Αυτό που δεν μπορώ να καταλάβω είναι τι αποσκοπείς να κερδίσεις.

Σε κάνει να νιώθεις ανώτερος κατά κάποιον τρόπο;

Ηδονίζεσαι;

Τί;

Ειλικρινά!

[defacer]

 

 

Σε περίπτωση που πράγματι δεν κατάλαβες (που πολύ αμφιβάλλω), σπάω το κεφάλι μου να καταλάβω γιατί πάντα θα πρέπει να συμπεριφέρεσαι τόσο απαξιωτικά και ελιτίστικα στο συνομιλητή σου.

Κατάλαβα πολλά και διάφορα, δεν είπα το αντίθετο. Αλλά στα πλαίσια της καλής συνεννόησης γενικά ρωτάω επειδή η άλλη επιλογή, να πάρω την υπόθεσή μου και να την πάω βόλτα, είναι αντιπαραγωγική.

 

Γιατί; Μερικές φορές γιατί δεν του αξίζει τίποτα καλύτερο. Κάποιες άλλες επειδή δεν του αξίζει αλλά κάνω λάθος εγώ για οποιοδήποτε λόγο -- και λόγοι να κάνω λάθη υπάρχουν αρκετοί. Και κάποιες επειδή δεν το βλέπω καθόλου έτσι αλλά ο απέναντι έχει αντίθετη γνώμη.

 

Στην προκειμένη σίγουρα δεν είμαστε στην πρώτη περίπτωση οπότε εφόσον σε τσάτισα σου ζητώ συγγνώμη.

 

Δεδομένου ότι:

  (1) Όλοι μπορούμε να φερθούμε έτσι, απλά οι υπόλοιποι το αποφεύγουμε από επιλογή κι όχι από αδυναμία, και

  (2) Ένας άνθρωπος της δικής σου νοημοσύνης αποκλείεται να το κάνει "παρορμητικά" και "κατά λάθος"

...συμπεραίνω εύλογα ότι το κάνεις συνειδητά και από επιλογή.

 

Αυτό που δεν μπορώ να καταλάβω είναι τι αποσκοπείς να κερδίσεις.

Σε κάνει να νιώθεις ανώτερος κατά κάποιον τρόπο;

Ηδονίζεσαι;

Τί;

Ειλικρινά!

Θα μου επιτρέψεις να πω ότι το συμπέρασμα είναι λάθος και αυτός ακριβώς είναι ο λόγος που και γω σε ρώτησα στα πλαίσια της καλής συνεννόησης παραπάνω. Η νοημοσύνη δεν είναι αρκετή για να μη γίνονται τέτοια λάθη, ίσα ίσα νομίζω ότι "η πολλή νοημοσύνη" σε κάτι τέτοια θέματα κάνει και κακό.

 

Όπως και να χει στην προκειμένη δεν το έκανα συνειδητά. Ίσως υποσυνείδητα καμιά φορά αλλά δε ξεκινάω να σου απαντήσω με σκοπό να βγει το συμπέρασμα ότι δεν ξέρεις τι σου γίνεται, αυτή την τιμή την έχει κερδίσει μόνο ένας.

 

Σ' αυτά τα θέματα (της γνώσης) βασικά ηδονίζομαι όταν νιώθω κατώτερος γιατί αυτό σημαίνει ότι έχω στόχο να βελτιωθώ. Granted πολλοί είναι αυτοί που θα ηδονίζονταν επειδή νιώθουν ανώτεροι ακόμα κι αν το ανώτερο είναι ο μονόφθαλμος αλλά δε λειτουργώ έτσι. Να νιώσει κανείς ανώτερος επειδή τι; Επειδή είναι ο καλύτερος στο τάδε random forum? LOL FFS έλα φίλε να πάρεις και μετάλλιο.

 

-----

 

Υπάρχουν κι άλλα που έχω να πω σχετικά με το θέμα αλλά δε σκοπεύω να κάνω αυτή την κουβέντα δημόσια. Απάντησα μια φορά δημόσια επειδή έμμεσα το ζήτησες κάνοντας το ίδιο, αλλά ο μόνος λόγος που βλέπω να συνεχιστεί αυτή η κουβέντα είναι καθαρά μεταξύ μας και θα πρέπει να γίνει με ΠΜ.