https://www.europesays.com/de/153618/ Polizei beschlagnahmt sechs Autos bei Kontrolle in Asterlagen #350 #Asterlagen #Dater #DE #Deutschland #Donuts #drehen #Duisburg #Germany #getroffen #NordrheinWestfalen #Poser #Raser #Städten #Szene

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

https://www.europesays.com/de/140119/ Poserszene in Stuttgart: Mehr als fünf Strafzettel täglich hinterm Rathaus #BadenWürttemberg #DE #Deutschland #Germany #Polizei #Poser #Stuttgart

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

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?

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?

#polizeiludwigshafen Originalschlagzeile mit #verantwortungsdiffusion

"Auto fährt in Straßenbahnhaltestelle"

"kam ein 24-Jähriger mit seinem Auto in der Saarlandstraße von der Fahrbahn ab, durchbrach das Glasgeländer der Straßenbahnhaltestelle "Wittelsbachplatz" und blieb auf dem Dach im Gleisbett liegen. Durch den Unfall wurden weder der Fahrer, noch andere Personen verletzt. An der Haltestelle befanden sich nach Zeugenaussagen keine wartenden Fahrgäste. Durch den Unfall entstand ein Sachschaden in Höhe von rund 10.000 Euro. Gegen den Fahrer wird wegen des Verdachts der Straßenverkehrsgefährdung ermittelt, da Zeugen beobachteten, dass der er mit überhöhter Geschwindigkeit den Unfall verursacht haben soll. Der Führerschein des 24-Jährigen wurde sichergestellt. Der Straßenbahnverkehr musste für über eine Stunde eingestellt werden."

Mal wieder nur Glück, dass keine unbeteiligten Passanten getötet wurden.

#Autoterror #Raser #Poser #Ludwigshafen

presseportal.de/blaulicht/pm/117696/6017123

In #Hockenheim hat ein Raser ohne Führerschein ein Kassenhaus des Hockenheimrings zerstört: Am #Motodrom

#PoizeiMannheim mit heftiger #verantwortungsdiffusion "möglicherweise auch aufgrund mangelnder Fahrpraxis" - wtf? #Framing #Autopolizei

Oder lag es doch daran, dass er gar keinen Führerschein hatte und mit völlig überhöhter Geschwindigkeit unterwegs war?

Und warum "vergißt" (?) PolizeiMannheim im Pressebericht zu erwähnt, dass das Kfz von einem Autohaus gemietet war?

Der Mieter beschreibt den Unfall so: "Ich habe gesehen, wie das Auto von hinten angeschossen kam, auf dem Schotter die Kontrolle verloren hat, sich quergelegt hat, gerutscht ist, bis an den Baum. Am Baum ist es dann mit der Front eingeschlagen, hat sich noch mal gedreht in die andere Richtung, ist dann hitner uns in die Hütte reingeschossen."

"Ein Totalschaden an einem BMW 850i und ein Gesamtschaden in Höhe von 80.000 - 100.000 Euro sind das Ergebnis des Fahrversuchs eines 19-Jährigen aus Hockenheim. ... Aufgrund nicht angepasster Geschwindigkeit und möglicherweise auch aufgrund mangelnder Fahrpraxis kam er nach rechts von der Straße ab, entwurzelte beim Aufprall mit dem PKW einen Baum und zerstörte ein zum #Hockenheimring gehörendes Kassenhäuschen.
Der 19-Jährige, der nicht im Besitz der erforderlichen Fahrerlaubnis ist, muss sich nun wegen Gefährdung des Straßenverkehrs, fahrlässiger Körperverletzung und Fahrens ohne Fahrerlaubnis verantworten."

youtube.com/watch?v=qvciG-cWmeg

presseportal.de/blaulicht/pm/14915/6016070

#Autoterror #Poser #Raser #carfriday

Grüße aus laut Politik angeblicher #Fahrradstadt #Mannheim:

HIer die Kontrollergebnisse von nur 1 (in Worten: einer) Nacht:

"Von Freitagabend bis in die Morgenstunden des Samstages wurden 132 Fahrzeuge und 176 Personen den Kontrollmaßnahmen unterzogen. Knapp 90 Verstöße konnten festgestellt und geahndet werden. Hierunter fielen diverse Verstöße bezüglich erkannter unzulässiger technische Veränderungen / Manipulationen von Fahrzeugen, unnötige Lärm und Abgasbelästigungen, als auch anderweitige verkehrsrechtliche Zuwiderhandlungen mit und ohne direkten Posing- und illegalem Tuningbezug. 6 Mal musste die Weiterfahrt mit dem jeweiligen Pkw untersagt und 6 Mal mussten die Fahrzeuge an sich sichergestellt werden, da die Verkehrssicherheit nicht unwesentlich durch die gegebenen gravierenden Mängel beeinträchtigt wurde.
Ferner fielen den Beamtinnen und Beamten auch zwei illegal geführte Kraftfahrzeugrennen mit fünf beteiligten Fahrzeugen auf. Dementsprechende Ermittlungsverfahren wurden eingeleitet. Vier Führerscheine und vier von fünf der beteiligten Pkw wurden letztlich beschlagnahmt."

#Poser #Raser #Carfriday Danke an #PolizeiMannheim dass sie es wenigstens versucht haben. Gerne heute Nacht gleich wieder.

presseportal.de/blaulicht/pm/14915/6016115

I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad.

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution.

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c

On a #coding mission to improve my #poser lib .

In the current implementation of #swad, I don't really like that I need an extra thread, just to control a child #process. A first piece to add to poser is generic "child process support", which I'm testing right now. I realized I could reuse my #Connection class, which was built for #sockets, but works just as well with #pipes

TODO now is mostly testing. See screenshots for some mimimal testing code and its output ... would you like this kind of interface?

Having to deprecate a part of #poser's API for the first time, I added support for the #deprecated attribute supported by #GCC and #clang and then found #Doxygen couldn't automatically use it.

I didn't want to document deprecation *twice*, so I came up with a little hackery, see screenshots.

It's not perfect, requiring to type the message in plain text as a macro argument forbids the usage of a comma But hey, it works!

https://zirias.github.io/poser/api/latest/deprecated.html