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

• #6032 Peter Kiss őstag beleszólok #6031

  Új Válasz 2014-11-18 17:47:16 #6032

  Ú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

  

  Peter Kiss

  őstag

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

  Ezért írtam a megjegyzésem is, szerintem a kérdést feltevők nem értenek hozzá.

  Ctor-ban nem inicializálunk static dolgokat, van static ctor, de annak nem lehet nyilván paramétere.

• #6006 sztanozs veterán beleszólok #6005

  Új Válasz 2014-11-14 17:59:21 #6006

  Ú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 #6005 üzenetére

  Mondjuk timestamp nem volt mellette
  Tapasztalatból az összes temporary megoldás permanent lesz, amint a termék működik

  teljesen normális, ha lehetőséget biztosítanak arra, hogy beállíts egy timeoutot, aminek lejártával zombinak minősítesz egy processzt. - ja és beállítod a zimbivá válás konstansát végtelenre; na arra aztán lehet várni

• #6004 sztanozs veterán beleszólok #6003

  Új Válasz 2014-11-14 17:18:17 #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