Feda /dev/ - No Javascript allowed

#45000 ¿ De que mutex hablas entonces ? Porque compartir un mutex entre dos procesos independientes lanzados por el user me parece a mi que no existe.

#45003 si creas un lockfile, el proceso peta y no borras el lockfile que?

edit: te respondo yo mismo...

#45004 Para eso tienes las utilidades especificas de cada SO, si estas en linux: https://linux.die.net/man/2/flock

Si tu proceso crashea, el SO libera el lock https://stackoverflow.com/a/12652718/4158710

#45005 Miralo como una oportunidad. Pon los huevos sobre la mesa, arregla esa puta mierda y enseñales quien sabe de verdad.

Por curiosidad, esta el que hizo todo eso en la empresa aun?

#45009 el primer parrafo lo escribi despues de hacer la solucion cabron...

y era una pregunta para reflexionar... que el codigo no esta claro con esa syscall que ocurre... XD

"mucho detalle bajo nivel a verificar"

y los flag de "wra" tiene semanticas distintas segun lo que hagas... era otro ejempo de que no esta claro el comportamiento, como el O_EXCL que sin el O_CREAT tiene undefined behavior por ejemplo... por ejemplo si haces un open(file, 'a').close() para crear un archivo que pasa? te parece que esa api es clara? xq no es lo mismo el 'a' que el 'w' en ese caso... porque el 'a' te crea el archivo si no existe...

Me has respondido a mi pregunta con mi respuesta si.

No se porque pierdo tanto tiempo con fperos la verdad.

#45001 Pero vamos a ver qué proceso orquestador ni qué pollas, si dices que te da por culo que el sistema operativo no lo maneje a nivel de kernel es porque quieres que todo se ejecute en la misma máquina, así que no necesitas un proceso externo que te gestione nada, o lo haces en tu código, o te vas a Torvalds, le comes la polla, y le pides amablemente que haga lo que quieres en el kernel.

#45002 No obstante, a petición de JuAnk4lv0 voy a poner un ejemplo de lo que hablo en C#:

• Ejecutable: https://www.mediafire.com/file/1oj5zl3c4y40or1/Multiprocess_Writer.zip/file
• Código fuente: https://www.mediafire.com/file/u10bix19bgsj5f6/Multiprocess_Writer_src.zip/file

using System;
using System.Collections.Generic;
using System.Security.Cryptography;
using System.Text;
using System.Threading;

namespace MultiprocessWriter {
    public class Mutexer {

        private Mutex __Mutex = null;

        public string MutexKey {
            get; private set;
        }

        public Mutexer(string Key) {
            this.MutexKey = this.__Hash(Key);

            this.__MutexInitialize();
        }

        private string __Hash(string Input) {
            using (SHA256Managed HashGenerator = new SHA256Managed()) {
                return BitConverter
                    .ToString(
                        HashGenerator.ComputeHash(
                            Encoding.UTF8.GetBytes(Input)
                        )
                    )
                    .Replace("-", "")
                ;
            }

            return Input;
        }

        public bool Acquire() {
            bool IsMutexNewly;
            this.__Mutex = new Mutex(true, this.MutexKey, out IsMutexNewly);

            // Mutex was created so ownership is guaranteed; no need to wait on it.
            if (IsMutexNewly) {
                Console.WriteLine($"[{this.MutexKey}] This mutex is fresh new!");

                return true;
            }

            // Mutex must be acquired
            try {
                if (!this.__Mutex.WaitOne(150, false)) {
                    return false;
                }
            }
            catch (AbandonedMutexException) {
                // Other application was aborted, which led to an abandoned mutex.
                // This is fine, as we have still successfully acquired the mutex.

                Console.WriteLine($"[{this.MutexKey}] This mutex was abandoned");
            }

            return true;
        }

        public bool AcquireWait(long Timeout = 0) {
            while (!this.Acquire()) {
                Console.WriteLine($"[{this.MutexKey}] Can't acquire mutex, waiting...");
                Thread.Sleep(150);
            }

            return true;
        }

        private void __MutexInitialize() {
            if (this.__Mutex != null) {
                this.__Mutex.Dispose();
            }

            this.__Mutex = new Mutex(false, this.MutexKey, out bool dummy);
        }

        public void Release() {
            try {
                this.__Mutex.ReleaseMutex();
            }
            catch (System.NullReferenceException) {
                __MutexInitialize();
            }
            catch (System.ObjectDisposedException) {
                __MutexInitialize();
            }
            catch (System.ApplicationException) { }
        }
    }
}

using System;

namespace MultiprocessWriter {

    public class Program {
        public static void Main(string[] args) {
            string Infile    = args[0];
            string ProcessID = args[1];

            bool Canceled = false;
            Console.CancelKeyPress += delegate (object? sender, ConsoleCancelEventArgs e) {
                Console.WriteLine($"[{DateTime.UtcNow.ToString("yyyyy-MM-dd HH:mm:ss.ffffff")}] [{ProcessID}] Program was cancelled!");

                Canceled = true;
            };

            Mutexer FileMutexManager = new Mutexer(Infile); 
            while (!Canceled) {
                FileMutexManager.AcquireWait();

                string LogMessage = $"[{DateTime.UtcNow.ToString("yyyyy-MM-dd HH:mm:ss.ffffff")}] [{ProcessID}] Ju4nk4lv0 le chupa el pito a desu";
                Console.WriteLine(LogMessage);
                File.AppendAllText(
                    Infile,
                    LogMessage+Environment.NewLine
                );

                Random RNG = new Random();
                Thread.Sleep(RNG.Next(250, 450));

                FileMutexManager.Release();

                RNG = new Random();
                Thread.Sleep(RNG.Next(50, 150));
            }
        }
    }
}

Ejemplos de uso:

• Lanzar 2 consolas con los siguientes comandos

"Multiprocess Writer.exe" sample_log_file.txt desu_1
"Multiprocess Writer.exe" sample_log_file.txt desu_2

Veréis que por un lado la consola lanzará mensajes diciendo que no puede adquirir el mutex cuando ambos están funcionando, esto dejará de suceder cuando haya 1 sola instancia funcionando.

Por otro lado, se escribirá en el fichero que hayáis especificado una línea con timestamp y el ID de la instancia (último parámetro).

Podéis lanzar tantas como queráis (cambiad el ID para distinguir mejor desde qué instancia se escribe al log).

Saludos: Un FPero.

#45016 Esta bien. Te agradezco que al menos, a diferencia de otros fperos hayas puesto codigo.

Pero para empezar windows != linux.

En windows si se permite lockear archivos como queria como ya comente mas posts atras.

Luego me miro tu codigo porque me parece interesante ver como funciona la API de windows.

#45017 tansolo se ha saltado la parte en que el problema lo tenemos con linux xq windows si funciona facil XD

#45019 Ya he mirado el codigo, si esta mal.

De nuevo, que lo tuyo funciona y esta genial si para tu solucion es suficiente.

Y te agradezco el aporte porque es una solucion implementando cosas que he dicho que NO quiero hacer.

Nosotros hablamos de que el kernel te levante el "mutex". No tener que hacerlo tu activamente con sleeps...

Gracias por el aporte pero esta mal.

Si quieres puedes volver a intentarlo porque Windows tiene syscalls que permiten hacer estas cosas de manera mejor que Linux.

Te has ganado que no te insulte despues de ver el codigo porque has tenido los huevos de ponerlo.

uncle bob siendo completamente destruido

https://github.com/cmuratori/misc/blob/main/cleancodeqa.md
https://github.com/cmuratori/misc/blob/main/cleancodeqa-2.md

en el 2 podeis leer el final, donde casey basicamente se rie en su puta cara

CASEY: Well, I disagree with most of that, but if we're ending it here, I'll just add my final responses for github posterity:

Regarding "as I wrote in Clean Code (which, by the way, is not the same as your "Clean Code")," well, the point of this discussion was for you to elaborate on what is not the same. But your design for this IO system looks exactly like my "Clean Code" example - a virtual function for every operation, and one class per element in the system with no predication. So what are these differences that you're referring to? Now would be the time to explain what they are, since that was the point of the concrete example. If this is a bad example for illustrating the differences, that's fine, but it was the first one you gave so I assumed it would be one you'd want to use.

Regarding "when operations proliferate more rapidly than types, switch statements are better," that was not the case here. In no way are operations proliferating more rapidly than types in this system. Vendors will add drivers to an OS constantly, perhaps monthly or even weekly, whereas the number of operations in a particular system tends to go up much more slowly (once every few months at maximum, but more like once a year for something like an IO subsystem). It is the opposite of what you said. This is an important distinction, because what I am demonstrating here is the opposite of your rule: this is showing that even in the case where types proliferate far more rapidly than operations, as is the case with drivers in an OS, the principle doesn't work. Enums are better in both cases. Specifically because you have potentially thousands of types in the system (all the different drivers all the vendors have ever shipped), adding a single operation, however rarely, can cost massive programmer cycles due to the unnecessary work multiplication across types that vtables cause. Another way to say this would be, enums are more important in a system where types proliferate rapidly, not less.

Regarding "you eventually chose a design that sacrifices machine cycles to save programmer cycles," I did no such thing. This design achieves both, that's why I like it. It is dramatically faster to use something like a packet-based system than something like your original proposed design, because you do not take a ring transition on every operation. New OS IO APIs are now all designed this way: the user writes data without talking to the OS, and a kernel thread picks up those data writes. Nobody ever makes a function call, except occasionally to ensure the kernel thread hasn't gone to sleep :) This is what I meant by the bullet point, "If at some point we decide that users should be able to do multithreaded/bulk IO ops" I am talking about the necessity that actually occurred in both Linux and Windows of removing the frequency of ring transitions for saving CPU cycles. None of this is trading CPU cycles for programmer cycles. It's achieving both. The Linux kernel design of io_uring looks like my design! They did not add that to save programmer cycles. They added it because they wanted the highest possible IO throughput. This is an almost universal principle of modern OS design: anything that can be turned into data writes should be, and function calls should be minimized. It's been true for GPUs, for NICs, and for our example, disk IO.

Regarding "And so I think we wind up in the same place. When operations proliferate more rapidly than types we both use switches. When types proliferate more rapidly than operations we both use dynamic dispatch," Again, I don't see how you got there. Obviously types are proliferating more rapidly in this system, so that part is not true. If we don't believe drivers are proliferating rapidly, why are we loading them dynamically? I thought that was the entire point of the example! But perhaps more importantly, we are not "using dynamic dispatch" here in the way you seem to be suggesting. As I said when I posted the proposed design, I would also do this inside the drivers themselves. I would not duplicate drivers to remove if statements and switches inside a driver that allowed that driver to handle multiple similar devices. The only reason there are function pointers in this system is because the problem definition required that we load the driver from a different module, and we are not presuming a JIT or something which can weld things together for us. That introduces a mandatory cut, so we cannot get rid of it because the problem is defined to contain it.

But note that that is not the same between our two approaches. I have the function pointer there because it's required. And you'll note I minimized the number all the way down to one. I didn't put it in there because I think it saves programmer time. In fact, I'm not really sure I want it there at all. I haven't actually implemented this particular system in an OS, so it was somewhat off the top of my head, but it's very possible that if I actually went to write this, I wouldn't actually include that function pointer at all. Instead, I might just have the OS thread reading the queue and prefiltering the packets for quota/permissions, then updating a shared memory address that lets the driver know it can process the packets directly. Without actually implementing, I can't say that's for sure what I would do, but, it's probably something I would try.

So it feels like you're overstating the similarity of our approaches, but, if you think they're that similar, then, I guess that's just where we end up! Thanks for taking the time to create this thread which pushed the github emoji checker well beyond its limits.

Bob: Thank you Casey. I believe we should let our disagreement stand at this point and let our audience be the final judge. This has been fun. Perhaps we'll do it again some day.

Fijaros como uncle bob no deja de irse por las ramas con casos hipoteticos, inventarse nuevo vocabulario para justificar sus analogias, decir cosas que casey no ha dicho y demas falacias...

Menuda master class del señor Muratori.

#45029 Es que es brutal el texto... me pasa mucho mucho estas cosas.

Uncle Bob es el tipico cuñao de toda la vida. Que no tiene ni puta idea de nada pero habla mucho. Con tecnicismos y analogias muchas hipotesis de un mundo ideal imaginario...

"ponme un poco de TDD en este singleton papi"

Menuda paciencia el señor Muratori si señor.

No entiendo como alguien como Uncle Bob ha accedido a hacer algo asi y dejar el ridiculo para la historia.

"a que hora ponen el stream de miudev juanillo? ahora manolo, despues de la clase de micro frontends hexagonales de codely!"