Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
A reproducible crash of CC
Loaden:
--- Quote from: oBFusCATed on August 08, 2011, 02:14:46 am ---Singleton is a global variable!!! They call it glorified global variable.
What do you gain by using singleton in this case? Instead of global variable or global variable hidden behind two functions cc::DebugLog and cc::Log (and of course one init function)?
BTW: Your Get() method is not thread safe:)
Also don't use double locking if you try to make it thread safe:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://bartoszmilewski.wordpress.com/2008/08/04/multicores-and-publication-safety/
--- End quote ---
In this case, we not need thread-safe for CCLogger::Get.
CCLogger::Get should call first in CodeCompletion::CodeCompletion():
--- Code: ---CodeCompletion::CodeCompletion() :
...
{
CCLogger::Get()->Init(this, idCCLogger, idCCDebugLogger);
--- End code ---
ollydbg:
--- Quote from: oBFusCATed on August 08, 2011, 02:14:46 am ---Also don't use double locking if you try to make it thread safe:
--- End quote ---
Which code use double locking? Can you give a direction in the CC's code(trunk HEAD)?
Loaden:
--- Quote from: ollydbg on August 08, 2011, 05:43:54 am ---
--- Quote from: oBFusCATed on August 08, 2011, 02:14:46 am ---Also don't use double locking if you try to make it thread safe:
--- End quote ---
Which code use double locking? Can you give a direction in the CC's code(trunk HEAD)?
--- End quote ---
if you try to make it thread safe:
:lol:
oBFusCATed:
--- Quote from: Loaden on August 08, 2011, 05:41:11 am ---In this case, we not need thread-safe for CCLogger::Get.
CCLogger::Get should call first in CodeCompletion::CodeCompletion():
--- End quote ---
So you're admitting that you're using this singleton as glorified global variable? :)
thomas:
Seeing how I'm the guy who wrote that apparently incomprehensible code, here's an explanation of how this was conceived:
* Logging uses a singleton, yes. There is no issue with that, it does not need locks. Making singletons threadsafe is a stupid, useless endeavor, because it does not work. It isn't an issue either, because the LogManager has been initialized ages before the CC plugin is ever loaded. After that, it is no more than a forwarded pointer.
* If you call DebugLog, this gets redirected (via 2 layers, if I remember correctly) to the concrete Logger object that is currently plugged in the debug_log slot. This enables, in theory, the application to for example start up in "no log" mode in case Code::Blocks runs in absence of GUI or even in absence of a terminal, or it allows a hypothetical Code::Blocks to send you e-mails for log messages.
* Loggers have exactly two requirements: They must implement the pure virtual Append function, and they must work in presence and absence of GUI and in presence or absence of several threads without crashing. Whatever, they must work without crashing.
* Loggerss are explicitly not required to do validation, or to produce meaningful or correct output or any output at all. It is perfectly acceptable for a Logger to output something ill-formatted or nothing at all, as long as it does not crash. If you fill shit into a logger, it's perfectly good if shit comes out of it.
* The reasoning behind the above was that there was the long-existent wish to make a commandline version of Code::Blocks which was impossible because every darn tiny function in the entire program called a log macro which required a GUI, just to output a text that nobody wanted to read, and there was no way to turn this off.
* TextCtrlLogger and his brethren, which are the ones used by default do not use a critical section, that is correct. This means that there is a race condition between control->SetDefaultStyle and control->AppendText. Thus, if an "error" and an "info" are logged concurrently, it is possible that the info is colored as an error or the other way around.
At the time of writing the class, I considered that since nobody would probably want to write thousands of log messages concurrently from half a dozen threads, this was unnecessary overhead, since the worst thing to happen would be wrongly colored messages, which I deemed a "so what" issue.
* There is no other reason (i.e. crash) which is obvious to me why you could not log concurrently. Unless wxWidgets GUI functions are not re-entrant, which I would seriously hope they are.
* There is, however, also no reason not to insert a critical section inside TextCtrlLogger::Append either, if you believe that this fixes a crash.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version