|
|
|
|
|
|
|
es gibt halt auch die „vernünftigen“, die C++ einfach als C mit klassen nutzen. da kommt dann kurioserweise zeuch bei raus, der sowohl vor-, als auch rückkompatibel ist.
das geheimnis liegt nach wie vor darin, weder die stl, noch boost zu nutzen. sondern etwas zu nehmen, was erm... etwas weniger gegen die wand gefahren wurde. soll nicht heissen, dass es da nicht hier und da mal ein paar sachen gibt, die nützlich sind, aber gut 98% von dem zeugs ist hoffnungsloser sondermüll, weil overengineered, zeugs reingepresst, weil man es kann, sachen einfach nicht wirklich unter berücksichtigung der nutzer blind entwickelt, etc.
ein wunderbares beispiel dafür sind die kompletten thread sachen aus der stl. man hätte es richtig machen können und tat dies auch, kurz vor schluss hat man sich dann für den dämlichen weg entschieden, der das zeugs in der realen welt, wo man halt mehr als fork and join nutzt, absolut unnutzbar macht.
|
|
|
|
|
|
|
|
|
|
|
Das Problem dabei ist halt, dass man sich zuerst den ganzen Kram zusammensuchen muss. Klar, mächtiges Werkzeug und Verantwortung und so, aber weil sich die C++ Community auch vehement wehrt, irgendwie sinnvolles package management einzuführen, endet das jedes Mal in einem gigantischen Akt. Ist dann halt kacke, wenn die Standardbibliothek der Sprache nicht wirklich benutzt werden kann.
¤: Also ich will das damit ja nicht irgendwie verteidigen. Boost ist der allerletzte Krebs. Aber ich kann eifach nachvollziehen, warum man die STL und Boost nutzen möchte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 31.07.2018 17:01]
|
|
|
|
|
|
|
|
|
|
Linux-Thread-STL-Ersatzlibrary-Liste?
|
|
|
|
|
|
|
|
|
|
|
Ich habe beim letzten C++ Projekt Boost verwendet. Seitdem bin ich mir sicher, dass es eine bessere Lösung geben muss.
¤: Disclaimer: Das ist über 10 Jahre her, seitdem verfolge ich das hauptsächlich von aussen. Aber traurigerweise hat sich an der Tooling und Librarylandschaft ja nicht vieles zum positiven verändert.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 31.07.2018 17:09]
|
|
|
|
|
|
|
|
|
C++ <3
libstdc++ <3
Traxer </3
|
|
|
|
|
|
|
|
|
|
|
ich hab hier ne interne lib, die neben ner gängigen container lib, ebenfalls algorithmen und platform abstraktion bietet.
platform abstraktion ist in dem fall hardware und OS/runtime. beinhaltet zusätzlich für die algorithmen, wo es sinn macht, ne simd variante.
der container teil sieht interfacemässig den C# containern recht ähnlich, halt aber mit den C/C++ sachen, die man dort halt benötigt.
zusätzlich gibts auch noch ne multithread, task infrastruktur, die sauber skaliert und neben nativen threads und job/task balancing auch noch fibres kann, das macht es an einigen stellen sehr angenehm damit zu arbeiten (der fibre part).
|
|
|
|
|
|
|
|
|
|
|
klingt spannend.
Wie laufen den Fibres in cpp? Bin da seit Jahren raus, gibt da was von Ratiopharm oder ist das schwarze setcontext Magie?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
es gibt halt auch die „vernünftigen“, die C++ einfach als C mit klassen nutzen. da kommt dann kurioserweise zeuch bei raus, der sowohl vor-, als auch rückkompatibel ist.
| |
Die Vorwärtsrichtung würde ich vehement bestreiten, denn wenn man wesentliche Konzepte der neueren (im Sinne von "dieses Jahrtausend") Versionen ignoriert, dann kann man die ganzen Vorteile nicht nutzen und das würde ich nicht gerade kompatibel nennen. Man kann den Code aufrufen - aber auf dem Level sind auch Java und C kompatibel. Was mein ursprünglicher Punkt war.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 31.07.2018 23:48]
|
|
|
|
|
|
|
|
|
Relevantes aus dem Funthread:
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von FreeHawk*
klingt spannend.
Wie laufen den Fibres in cpp? Bin da seit Jahren raus, gibt da was von Ratiopharm oder ist das schwarze setcontext Magie?
| |
wenn du nicht gerade auf nem system bist, was das nativ unterstützt, dann ist da genau die magic im spiel oder halt ne hand voll asm.
|
|
|
|
|
|
|
|
|
|
|
Ich werde nie ein guter Programmierer 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
ein wunderbares beispiel dafür sind die kompletten thread sachen aus der stl. man hätte es richtig machen können und tat dies auch, kurz vor schluss hat man sich dann für den dämlichen weg entschieden, der das zeugs in der realen welt, wo man halt mehr als fork and join nutzt, absolut unnutzbar macht.
| |
Weil es gerade so schön passt:
| | | This was all the committee could agree upon. In particular, representatives from POSIX were vehemently against any form of ``thread cancellation'' however much C++'s model of resources rely on destructors. There is no perfect solution for every systems and every possible application. | |
http://stroustrup.com/C++11FAQ.html#std-threads
Dass es die Portabilität erschwert ist logisch. Weiß jemand warum konkret die Leute von POSIX gegen eine API im Standard waren, die ein Abbrechen von Threads erlaubt?
POSIX bietet über pthread_cancel() eine Abbruchfunktion. Ob diese Funktion überhaupt wirkt, kann mit pthread_setcancelstate() (default ON) und pthread_setcanceltype() gesteuert werden. Der Canceltype gibt an, ob der Thread bei erreichen eines Cancelpoints abgebrochen (default) wird oder sofort. Es gibt eine Reihe von Funktionen die laut Standard Cancelpoints sind oder man fragt mit pthread_testcancel() manuell. Und dann kann man noch Aufräumarbeiten definieren, mit pthread_cleanup_push()/pop().
Traxer?
Auch hier wird es nicht erklärt. Befürchteten die vielleicht nachteilige Kompromisse mit Leute um Win32?
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 01.08.2018 15:32]
|
|
|
|
|
|
|
|
|
schau dir einfach mal den "horror" an, den du so in den pthread headern finden kannst, der für die C++ unterstützung gedacht ist.
im prinzip ist es aber recht einfach, thread cancellation ist eine ganz beschissene idee und hätte niemals irgendwo existieren sollen. kaum einer weiss, wie das anzuwenden ist, kaum einer macht es richtig.
das ist selbst in C ne ziemlich dämliche sache.
das grundlegende problem besteht darin, dass thread cancellation (unix) / termination (windows) nicht klar definiert ist. selbst auf unix/linux nicht. es kann an einem vordefinierten cancellation point passieren, es kann aber auch einfach so, irgendwo passieren. hängt komplett von der implementation ab.
im fall von C ist das, als wenn du den thread mit nem kill -KILL abknallst. was da auch effektiv passiert. aufräumen von irgendwelchen sachen ist da nicht. ausser du sorgst vor und machst das im main oder sonstigen anderen threads.
die cancellation points sind teilweise nicht dokumentiert, soll heissen, dass du nicht unbedingt weisst, ob eine funktion das macht oder nicht. nahezu alle I/O funktionen sind cancellation points, aber nicht alle syscalls...
das testcancel dingen kannst du selber in drei zeilen umsetzten, atomare variable, entweder gesetzt oder nicht.
auf windows und einigen anderen systemen ist ein TerminateThread (win) ein direkter kill des threads, da gibt es keine cancellation points. das instruiert den kernel, den thread sofort und ohne irgendwas anderes zu töten.
auf einigen POSIX platformen ist das ebenfalls so gelöst.
im kontext von C++ wird das ganze irrsinnig, weil du in dem fall keine möglichkeit mehr hast nen destruktor laufen zu lassen. es kann damit also sein, dass du nicht mal mehr an die instanz deiner thread klasse kommst, weils die gerade aus dem system gekillt hat.
es kann natürlich auch sein, dass du gerade während der ausführung eines con/destructors nen terminate/cancel reinbekommst und dann? im constructor könntest du jetzt einfach ein ungeformtes objekt zerlegen, mit glück hast du vorher keine heap sachen allokiert, da läuft dann halt kein destruktor mehr, weil den gibts da dann nicht.
knallt dir das teil eine während du im destruktor bist, nunja. dann ist dein objekt weg, aber im ungünstigsten fall nichts von den sachen, die der aufräumen sollte und du hast keine wirkliche möglichkeit mehr diese sachen aufzuräumen, weil alle deine referenzen / pointer weg sind. ups.
das wäre jetzt aber nichtmal eines der "features", die ich vermisse und die dämlich gelöst sind. wie gesagt, wer das nutzt der muss damit leben, dass er sich beim fuss weg schiessen, gleichzeitig noch die arme, den kopf und die person hinter sich mit nimmt.
|
|
|
|
|
|
|
|
|
|
Frankenthread
|
Danke. Bestätigt meine Denken, der schlimmste Teil ist wohl die Destruktorhandhabung, weil es die Freigabe der Ressourcen betrifft.
Man ist ja frei die nativen POSIX- bzw. LINUX-APIs zu verwenden. Aber wenn man den Canceltype auf PTHREAD_CANCEL_DEFERRED setzt und auf einen vom System gegeben oder mit pthread_testcancel() selbst definierten Cancelpoint wartet, um dann mit Hilfe von pthread_cleanup_push() aufzuräumen - dan kann man den Thread gleich geordnet, in freiwilliger Kollaboration, beenden. Der Fall von Notwehr gegen einen Thread dürfte es selten geben, dann wäre PTHREAD_CANCEL_ASYNCHRONOUS die Wahl. Die Manpage dazu:
| |
Setting the cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS is rarely useful. Since the thread could be canceled at any time, it cannot safely reserve resources (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks, and so on. Reserving resources is unsafe because the application has no way of knowing what the state of these resources is when the thread is canceled; that is, did cancellation occur before the resources were reserved, while they were reserved, or after they were released? Furthermore, some internal data structures (e.g., the linked list of free blocks managed by the malloc(3) family of functions) may be left in an inconsistent state if cancellation occurs in the middle of the function call. Consequently, clean-up handlers cease to be useful. Functions that can be safely asynchronously canceled are called async-cancel-safe functions. POSIX.1-2001 only requires that pthread_cancel(3), pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe. In general, other library functions can't be safely called from an asynchronously cancelable thread. One of the few circumstances in which asynchronous cancelability is useful is for cancellation of a thread that is in a pure compute-bound loop. | |
Der letzte Satz beschreibt dann einen theoretischen Fall, dabei dürfen keine Resourcen angefordert werden und wohl auch nicht Manipuliert werden. Ich habe die kranke Idee nach einem String in einem Index suchen zu lassen, wenn sich der String aber in der zwischenzeit ändert, den suchenden Thread aus dem Leben zu befördern. Dabei mache ich dann sicher etwas falsch, etwa indirekt eine Resource anfordern und habe undefinietes Verhalten. Mit einem Subprozess und eigenem Speicher wäre schlauer? Weil richtig?
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 02.08.2018 10:51]
|
|
|
|
|
|
|
|
|
Hat jemand noch ein X200/201, X60/61 oder T60/61? Wenn ihr zu viel Zeit habt und kein neues Gerät möchtet, hier gibt ein neues Innenleben, sogar mit Quadcore für das X200/201! Website lädt langsam und irgendwie läuft das über Facebook oder so, aber nette Sache 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 03.08.2018 10:00]
|
|
|
|
|
|
|
|
|
Mist, gerade vor 3 Wochen das von meiner Freundin auseinandergebaut weil der Kartenlesen rummuckt. Aber mein Chinesisch ist nicht so grossartig  : unterstützt das alle Hardware, sprich auch Dock etc?
|
|
|
|
|
|
|
|
|
|
|
Hat das schon mal jemand ausprobiert, der englisch oder deutsch schreibt? Sprich in irgendeinem Thinkpadforum oder sowas?
Aber die Idee ist geil. Mein X200 gefaellt mir vom Formfaktor so gut, dass ich es weiter nutzen will.
|
|
|
|
|
|
|
|
|
|
|
Nicht in Deutsch, aber auf Englisch. Matthew Garret hat es ausprobiert und überprobiert. Direkt nach dem ersten Absatz eskaliert das Ganze, da ist er schon fertig.
Er hat dann noch das BIOS entfernt und durch ein selbst angepasstes Coreboot ersetzt. Das ist der Programmierer hinter Security-Lock-Down und versucht sogar SecureBoot etwas positives abzugewinnen.
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 03.08.2018 11:13]
|
|
|
|
|
|
|
|
|
|
Verstehe ich das richtig, dass man nur ein komplettes Gerät kriegt?
|
|
|
|
|
|
|
|
|
|
|
Ich verstehe es auch nicht ganz. Die Website erweckt den Eindruck, dass man nur ein Umbaukit aus Mainboard und Display bekommt, aber sie scheinen tatsächlich komplett umgebaute Laptops zu verkaufen. Hier gibt es womöglich mehr Informationen auf Deutsch. Chinesisch ist nicht gerade die Lingua Franca und deren englische Kommunikation auch nicht perfekt.
Andererseits brauchst du dann kein X201 mehr herumliegen. Notebookcheck hat sich wohl ein X60 bestellt 
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 03.08.2018 11:39]
|
|
|
|
|
|
|
|
|
Englisch ist mir auch recht, aber ich habe mich jetzt durch etliche Facebookkommentare gekämpft und bin immer noch nicht schlauer geworden 
¤: Ich habe mehrere X201, deswegen will ich kein zusätzliches mehr.
Ein wenig google foo sagt mir, dass offenbar das hier nur aus Motherboard + Cooler besteht, und man das dann selber basteln kann. Die Anleitung wie man das dann aber reinkriegt ist wiederum nur auf Chinesisch...
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 03.08.2018 11:38]
|
|
|
|
|
|
|
|
|
|
Ich habe auch den Eindruck, dass einige Leute nur die Einzelteile bestellen und einbauen und andere ein fertig umgebautes Laptop bestellen.
|
|
|
|
|
|
|
|
|
|
|
|
LCDFans verkauft fertige Geräte, das Motherboard an sich gibt es offenbar nur innerhalb von China zu bestellen. Das ist wiedermal so ein Fick den ich mir wohl eher nicht geben möchte
|
|
|
|
|
|
|
|
|
|
|
Sollte es trotzdem ernst werden, kann ich meine chinesische Kollegin fragen, ob sie mir eine sinngemäße Kurzfassung geben kann.
Ich bin mit meinem X220 sowieso glücklich. Wobei ich beim T420 bemerkt habe, dass die Displayaufhängung auf der linken Seite über der CPU sehr heiß werden kann. Nimmt die wärme direkt vom Kühler ab.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 03.08.2018 11:49]
|
|
|
|
|
|
|
|
|
|
Im Thinkpadforum hat auch jemand ein komplettes Geraet bekommen.
|
|
|
|
|
|
|
|
|
|
|
wie bekommt man eigentlich am einfachsten raus, warum ein t42 sich tod stellt? ich dachte zuerst noch dran, dass es der akku ist, aber auch mit netzteil dran tut es genau gar nichts mehr.
gibt es da irgendeine „einfache“ möglichkeit rauszubekommen was das problem ist? ich würde das nämlich ganz gerne für so simple sachen wie administration von geräten verwenden, als auch für ein paar andere sachen, die man halt noch mit nem single core pentium m machen kann.
|
|
|
|
|
|
|
|
|
|
|
|
In der Stromversorgung haben die Sicherungen drin. Schaltpläne gibts im Netz.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ufff... bleichenbacher ist dem wohl halt wirklich kein begriff.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
