2. Fórumok
  3. Szoftverfejlesztés
  4. C# programozás
Keresés

Új hozzászólás Aktív témák

  • #6004 sztanozs veterán beleszólok #6003
    Új Válasz #6004
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    sztanozs

    veterán

    válasz beleszólok #6003 üzenetére

    c# angol kommentek érdekesek :)

    Találkozás a végzettel:
    mscorlib/system/threading/Tasks/ConcurrentExclusiveSchedulerPair.cs:243
    // Now that we're doomed, request completion
    RequestCompletion();

    Zombivá vált producer...
    System.Core/System/Linq/Parallel/Scheduling/Scheduling.cs:52
    // The number of milliseconds before we assume a producer has been zombied.
    internal const int ZOMBIED_PRODUCER_TIMEOUT = Timeout.Infinite;

    A csúf múlt
    mscorlib/system/reflection/emit/isymwrappercore.cs:27
    // Ideally we wouldn't need ISymWrapper.dll on desktop either - it's an ugly piece
    // of legacy. We could just use this (or COM-interop code) everywhere, but we might
    // have to worry about compatibility.

    Szerintem nem kell, de nem tudom bizonyítani...
    System/services/monitoring/system/diagnosticts/EventLogInternal.cs:1097
    // NOTE, [....]: ERROR_PROC_NOT_FOUND used to get returned, but I think that
    // was because I was calling GetLastError directly instead of GetLastWin32Error.
    // Making the buffer bigger and trying again seemed to work. I've removed the check
    // for ERROR_PROC_NOT_FOUND because I don't think it's necessary any more, but
    // I can't prove it...

    Nem tűnik a legjobb megoldásnak, de így hagyom...
    mscorlib/system/globalization/compareinfo.cs:361
    // some NLS VM functions can handle COMPARE_OPTIONS_ORDINAL
    // in which case options should be simply cast to int instead of using this function
    // Does not look like the best approach to me but for now I am going to leave it as it is

    Nem teljesen értem miért működik, így inkább nem piszkálom.
    mscorlib/system/reflection/emit/methodbuilder.cs:736
    // We used to always "tokenize" a MethodBuilder when it is constructed. After change list 709498
    // we only "tokenize" a method when requested. But the order in which the methods are tokenized
    // didn't change: the same order the MethodBuilders are constructed. The recursion introduced
    // will overflow the stack when there are many methods on the same type (10000 in my experiment).
    // The change also introduced race conditions. Before the code change GetToken is called from
    // the MethodBuilder .ctor which is protected by lock(ModuleBuilder.SyncRoot). Now it
    // could be called more than once on the the same method introducing duplicate (invalid) tokens.
    // I don't fully understand this change. So I will keep the logic and only fix the recursion and
    // the race condition.

    Ezt a részt nem fogom karbantartani.
    system/threading/Tasks/Parallel.cs:3421
    // I'm not going to try to maintain this

Új hozzászólás Aktív témák