In der Überseestadt hat die Bremer Polizei zahlreiche Fahrzeuge kontrolliert. Mehrere Verkehrsteilnehmer erhielten Anzeigen – auch wegen unnützem Herumfahrens. #Poser #Raser #Kontrolle

Bremen: Polizeikontrollen enth...

Ein Lob und ein Dankeschön an #PolizeiMannheim

#Poser und #Raser terrorisiert um 1:00 h nachts die Anwohner in #Mannheim

"In der Nacht von Freitag auf Samstag, kurz nach 01:00 Uhr nahmen Beamte des Polizeirevier Mannheim-Oststadt in der Augustaanlage ein Porsche Boxster wahr, der sich akustisch frühzeitig ankündigte: Der Motor heulte laut auf, noch bevor der Wagen sichtbar wurde. Kurz darauf raste das Fahrzeug mit deutlich überhöhter Geschwindigkeit an der Streife vorbei. Haltesignale wurden schlicht ignoriert. Die Verfolgung wurde von der Streifenbesatzung sofort aufgenommen. Die Fahrt endete dann in einem Parkhaus, wo der Fahrer dachte, dass er unentdeckt ein Parkticket ziehen und mit quietschenden Reifen in die Tiefgarage einfahren kann. Der Versuch, sich zu Fuß davonzustehlen, scheiterte ebenfalls: Der junge Mann sprach mehrere Passanten an, ihn doch bitte für 100,- Euro nach Hause zu fahren. "Zu viel Polizei" sei unterwegs, erklärte er. Die Rückkehr zum Parkhaus mit einem der Zeugen brachte ihn schließlich direkt zu zwei wartenden Polizeibeamten. Der 21-Jährige verweigerte zunächst die Herausgabe seiner Personalien und zeigte sich sehr unkooperativ. Letztendlich musste er nach seinen Ausweispapieren durchsucht werden. Im Rahmen dieser Maßnahmen ergaben sich auch die ersten Hinweise auf möglichen Alkoholkonsum. Da der Mann einen Atemalkoholtest verweigerte, musste im eine Blutprobe entnommen werden. Das Ergebnis der Blutentnahme steht noch aus. Den Fahrer erwartet nun ein Strafverfahren, unter anderem wegen des Verdachts auf ein illegales Kraftfahrzeugrennen und Trunkenheit im Verkehr."

Was wohl die Konsequenzen sind? Wir werden es dank intransparenter Justiz nie erfahren 😬

Wenn euch Poser und Kfz in Mannheim auffallen, deren Fahrer*innen den Motor aufheulen lassen, meldet das bitte der Polizei: mannheim.pp@polizei.bwl.de

presseportal.de/blaulicht/pm/14915/6055191

#Autoterror #Autostadt

The #lockfree command #queue in #poser (for #swad) is finally fixed!

The original algorithm from [MS96] works fine *only* if the "free" function has some "magic" in place to defer freeing the object until no thread holds a reference any more ... and that magic is, well, left as an exercise to the reader. 🙈

Doing more research, I found a few suggestions how to do that "magic", including for example #hazardpointers ... but they're known to cause quite some runtime overhead, so not really an option. I decided to implement some "shared object manager" based on the ideas from [WICBS18], which is kind of a "manually triggered garbage collector" in the end. And hey, it works! 🥳
https://github.com/Zirias/poser/blob/master/src/lib/core/sharedobj.c

[MS96] https://dl.acm.org/doi/10.1145/248052.248106
[WICBS18] https://www.cs.rochester.edu/u/scott/papers/2018_PPoPP_IBR.pdf

#coding #c #c11 #atomics

This redesign of #poser (for #swad) to offer a "multi-reactor" (with multiple #threads running each their own event loop) starts to give me severe headaches.

There is *still* a very rare data #race in the #lockfree #queue. I *think* I can spot it in the pseudo code from the paper I used[1], see screenshot. Have a look at lines E7 and E8. Suppose the thread executing this is suspended after E7 for a "very long time". Now, some dequeue operation from some other thread will eventually dequeue whatever "Q->Tail" was pointing to, and then free it after consumption. Our poor thread resumes, checks the pointer already read in E6 for NULL successfully, and then tries a CAS on tail->next in E9, which is unfortunately inside an object that doesn't exist any more .... If the CAS succeeds because at this memory location happens to be "zero" bytes, we corrupted some random other object that might now reside there. 🤯

Please tell me whether I have an error in my thinking here. Can it be ....? 🤔

Meanwhile, after fixing and improving lots of things, I checked the alternative implementation using #mutexes again, and surprise: Although it's still a bit slower, the difference is now very very small. And it has the clear advantage that it never crashes. 🙈 I'm seriously considering to drop all the lock-free #atomics stuff again and just go with mutexes.

[1] https://dl.acm.org/doi/10.1145/248052.248106

I now implemented a per-thread #pool to reuse #timer objects in #poser (my lib I use for #swad).

The great news is: This improved performance, which is an unintended side effect (my goal was to reduce RAM usage 🙈😆). I tested with the #kqueue backend on #FreeBSD and sure, this makes sense: So far, I needed to keep a list of destroyed timers that's always checked to solve an interesting issue: By the time I cancel a timer with #kevent, the expiry event might already be queued, but not yet read by my event loop. Trying to fire events from a timer that doesn't exist any more would segtfault of course. Not necessary any more with the pool approach, the timer WILL exist and I can just check whether it's "alive".

The result? Same hardware as always, and now swad reaches a throughput of 26000 requests per second with (almost) perfect response times. 🥳

I'm still not happy with memory usage. It's better, and I have no explanation for what I oberved now:

Ran the same test 3 times, 1000 #jmeter threads each simulating a distinct client running a loop for 2000 times doing one GET and one POST for a total of 4 million requests. After the first time, the resident set was at 178MiB. After the second time, 245 MiB. And after the third time, well, 245 MiB. How ...? 🤯

Also, there's another weird observation I have no explanation for. My main thread delegates accepted connections to worker threads simply "round robin". And each time I run the jmeter test, all these worker threads show increasing CPU usage at a similar rate, until suddenly, one single thread seems to do "more work", which stabilizes when this thread is utilizing almost double the CPU as all other worker threads. And when I run the jmeter test again (NOT restarting swad), the same happens again, but this time, it's a *different* thread that "works" a lot more than all others.

I wonder whether I should accept scheduling, memory management etc. pp are all "black magic" and swad is probably "good enough" as is right now. 😆

#Ketsch #Autoterror #Poser

"Am Samstag gegen 22 Uhr fuhr in der Straße "Im Bruch" ein 20-jähriger Mann mit einem hochmotorisierten Mercedes GLS AMG gezielt auf mehrere Kinder zu, welche sich auf dem Heimweg befanden. Lediglich ein Sprung zur Seite verhinderte eine Kollision. Anschließend soll der 14-jährige Bruder des Fahrers aus dem Beifahrerfenster des Wagens eine Pistole gehalten und mehrere Passanten bedroht haben."

www.presseportal.de/blaulicht/pm/14915/6047344

👮 Verkehrskontrolle in #Mannheim am Freitag abend, Fokus 🏎️ #Poser #Raser

Ergebnis:
- Fressgasse: 55 Geschwindigkeitsübertretungen
- D7 C7: 87 Geschwindigkeitsübertretungen
- Innenstadt: 90 Halte- und Parkverstöße (nur 90? 👀)
- 23 x Telefonnutzung am Steuer
- 16 x unnötiger Lärm
- 28 x fahren unter Missachtung Gurtpflicht
- 10 x unzulässige technische Veränderungen
- 23 x unbehebbare Mängel mit Wiedervorführung Kfz
- 5 x technische Überprüfung

96 Fahrzeuge kontrolliert

https://presseportal.de/blaulicht/pm/14915/6047772

@padeluun Kann ich absolut nachvollziehen!
#Poser #Tuner #tunercars

In der Nacht zu Donnerstag hat die Polizei in mehreren Stadtteilen illegale Straßenrennen gestoppt. Gleich drei teilweise hochmotorisierte Autos wurden beschlagnahmt. #Poser #Raser #Autoirre

Mit mehr als 90km/h durch die ...

Never play to the gallery.

https://foxandthistle.studio/collections/offhand-cards

#art #peoplepleasers #music #authenticity #unique #players #fake #poser #noshame

Mid way implementing "multi-threaded #reactor" (multiple event loops in parallel) in #poser for usage in #swad and it's going like expected. Debugging heavily multi-threaded stuff is really a PITA. 🤯

So, #swad [1] 0.11 handles the simulated 1000 concurrent and distinct clients on my mediocre machine at an overall rate of more than 1000 requests per second. That's *probably* good enough for reasonably busy sites now.

Still not really happy because observing this with #top, I've seen the main thread almost max out a core, while all the pool threads (running the request pipelines after basic HTTP decoding done in the main thread) were almost idle (less than 1% CPU usage).

To fully use the computing power of all CPU cores in this scenario (swad's request handlers are relatively simple and quick), I'd need a different design. Multiple #reactor threads, with the acceptor-connector pattern (one just watching the socket(s) for new connections, feeding them round-robing to "child" reactors running their own event loop) comes to mind. I *think* #nginx is doing something similar.

But that's really a massive change resulting in a pretty complex design. Not sure whether I should try to tackle that. On the plus side, it could make my #poser lib suitable for building "high performance" services... 🤔

[1] https://github.com/Zirias/swad

#coding #c

First step towards implementing #JWT in #swad done, just committed a good 1000 LOC and now my #poser lib can do #JSON 😎
https://github.com/Zirias/poser/commit/7f1772e85c869d544f8a12099ed6545e163dc163

Seems a first step is almost done, adding #JSON support to my #poser lib. This could be the foundation for #JWT support in #swad. 😎

Need to do more thorough testing I guess, but at least the two example documents from #rfc8259 work fine ... the test tool does a full #deserialization / #serialization roundtrip (with specific internal representations of the data types supported by JSON).

edit: Look at the "Longitude" value of the second object in the second example 😏 I only noticed myself right now, but of course that's the desired behavior.

Now that #swad 0.7 is released, it's time to prepare a new release of #poser, my own lib supporting #services on #POSIX systems, following a #reactor with #threadpool design.

During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. #select) to auto-detected support for #kqueue, #epoll, #eventports, #signalfd and #timerfd (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a #dictionary using nested hashtables internally, or #async tasks mimicking the async/await pattern known from e.g, #csharp. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).

I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....

And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔

Stay tuned, something will come here, maybe helping you to write a nice service in plain #C 😎:

https://github.com/Zirias/poser

Poser? All This Guy’s Friends Are Alive

https://fed.brid.gy/r/https://thehardtimes.net/blog/poser-all-this-guys-friends-are-alive/

The next release of #swad will probably bring not a single new feature, but focus on improvements, especially regarding #performance. Support for using #kqueue (#FreeBSD et al) to handle #signals is a part of it (which is done and works). Still unsure whether I'll also add support for #Linux' #signalfd. Using kqueue also as a better backend for #timers is on the list.

Another hopefully quite relevant change is here:

https://github.com/Zirias/poser/commit/798f23547295f89fa0c751f0e707c3474b5c689c

In short, so far my #poser lib was always awaiting readiness notification (from kqueue, or #epoll on Linux, or select/poll for other platforms) before doing any read or write on a socket. This is the ideal approach for reads, because in the common case, a socket is NOT ready for reading ... our kernel must have received something from the remote end first. But for writes, it's not so ideal. The common case is that a socket IS ready to write (because there's space left in the kernel's send buffers). So, just try it, and only register for notifications if it ever fails, makes more sense. Avoids pointless waiting and pointless events, and e.g. with epoll, even unnecessary syscalls. 😉

Hmm. Now that I have a working "generic" #signal handling in #poser, I'd like to optimize a bit by picking up @david_chisnall's suggestion to use #kqueue for the job if available. Would have a clear advantage: No need to fiddle with the signal mask around every call to #kevent.

I still had the doubt whether a signal delivered via kqueue would still remain pending when it is just blocked, so I wrote some little test code and the unfortunate answer is: yes. Unfortunate because I want my library code to restore everything as it was found (signal mask and handlers) on exit, but I certainly don't want a batch of spurious signals handled when unblocking them.

Kind of obvious solution: Set the signals temporarily to ignored when unblocking them, as shown in the screenshot. Now I have the next doubt: Is it guaranteed to have pending signals delivered instantly when unblocking them? 🤔

#FreeBSD #coding

Ein #Raser / #Poser weniger in #Mannheim 🌈

"Am Dienstag kontrollierte um kurz vor 21:30 Uhr eine Streife des Polizeireviers Mannheim-Innenstadt einen BMW in der Marktstraße. Das Fahrzeug war der Streife aufgrund einer übermäßigen Geräuschentwicklung aufgefallen. Bei der genauen Inaugenscheinnahme des Fahrzeugs fanden sich zahlreiche Mängel und Veränderungen. So war die Abgasanlage manipuliert worden, damit sie deutlich lauter war, als eigentlich erlaubt. Auch am Fahrwerk und den Reifen konnten unzulässige Veränderungen festgestellt werden. Die Polizei untersagte dem 22-Jährigen Fahrer aufgrund der schwerwiegenden Mängel die Weiterfahrt und stellte das Auto sicher. Der 22-Jährige muss nun mit einem Bußgeld rechnen."

presseportal.de/blaulicht/pm/14915/6023343

#Autoterror #Autoterroristen #Lärmterror

I'm trying to add "genric" #signal handling to #poser. Ultimate goal is to provide a way for #swad to handle #SIGHUP, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).

Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in #SIGINFO which doesn't even exist on all platforms ... 🤔

Now, #POSIX specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on #Linux? Should I check #NSIG and, if not defined, just define it to 64? 🙈

#C #coding #question