Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Non-DDE IPC?
TheNullinator:
I'm putting finishing touches on the WM_COPYDATA IPC system now. I'll finish them tomorrow hopefully. It works fine under Windows ME (ANSI) and Windows XP (ANSI/unicode). It works good over a network aswell. It is fully supportive of multiple instances of Code::Blocks and sends files to the last active window so you can choose which one you want to receive a file.
There are two problems I've come across so far. They are:
* Sometimes a message is displayed saying the config file couldn't be saved. This happens only when wildly double clicking on C::B registered files (in particular non-projects/workspaces) in Windows Explorer.
* If the first instance is still loading and another codeblocks.exe is executed with a file argument and the first instance crashes while loading a plugin, the codeblocks.exe with the file argument hangs.
The first issue seems to have been fixed with some timed retry mods to CfgMgrBldr::Close(). I'm going to find some other way around that one though. I've got an idea about the second one, too.
I'll upload a diff file when those issues are fixed (and any others that may arise) so if you guys want to use it, then that's cool. Otherwise, I had fun doing it anyway. :)
Cheers
thomas:
--- Quote ---The first issue seems to have been fixed with some timed retry mods to CfgMgrBldr::Close().
--- End quote ---
Eeeeeeeeh... please do not ever tamper with that function. This is absolutely no go.
First of all, it is not recommended to use CfgMgrBldr for anything at all. The actual reason why CfgMgrBldr has such a stupid name is to give you a hint that this is not thought to be used in normal operation. Treat it as if it was a private internal class of Manager (although it is not, for simplicity).
Also, calling Close() will result in undefined behaviour, and will leak memory - use Free() instead. However, it is best if you don't use Free() either, since that, too, may result in undefined behaviour.
The configuration manager and all pointer references to it are, by definition, valid from its first invokation to the destruction of the Manager singleton (which happens immediately before the application is terminated). Parts of the SDK rely on this fact and may crash if you destroy ConfigManager.
The same or similar is true for other managers. The shutdown procedure follows a well-defined order of destruction which ensures that certain things are reliably availabler at given times.
For example, a plugin developer can rely blindly on the availability and validity of ScriptingManager, ProjectManager, EditorManager, PersonalityManager, MacrosManager, UserVariableManager, MessageManager, and ConfigManager (no null-pointer checks required!) for the entire lifetime of a plugin.
Also, this ensures that for example EditorManager is valid for the entire lifetime of ProjectManager, because the former is used by the latter.
If you free managers in an uncontrolled manner, these contraints are no longer effective and very, very nasty things (which are impossible to debug) may happen.
What can be done is, you can simply do all your IPC before ConfigManager is instantiated for the first time. In that case, nothing is saved to the config.
TheNullinator:
--- Quote from: thomas on April 06, 2006, 07:52:43 pm ---
--- Quote ---The first issue seems to have been fixed with some timed retry mods to CfgMgrBldr::Close().
--- End quote ---
Eeeeeeeeh... please do not ever tamper with that function. This is absolutely no go.
--- End quote ---
Yeah, I thought it was a bit of an out-of-the-way function. That's why I'm looking for a different way. The original version of the IPC code needed the config file to check /environment/single_instance but I rewrote a lot of it yesterday to support mutliple instances so I can move everything to before ConfigManager is instantiated.
--- Quote from: thomas on April 06, 2006, 07:52:43 pm ---Also, calling Close() will result in undefined behaviour, and will leak memory - use Free() instead. However, it is best if you don't use Free() either, since that, too, may result in undefined behaviour.
--- End quote ---
I never called Close(), it got called naturally through CfgMgrBldr::~CfgMgrBldr() when the applicated terminated. It just happened to happen at the same time in two different instances of Code::Blocks that were sending IPC messages.
thomas:
--- Quote ---I never called Close(), it got called naturally through CfgMgrBldr::~CfgMgrBldr() when the applicated terminated. It just happened to happen at the same time in two different instances of Code::Blocks that were sending IPC messages.
--- End quote ---
Ah ok, that is something we'll have to live with then, because I am not using a Windows mutex for portability (only way we could avoid that). wxWidgets mutexes don't work between processes... :(
TheNullinator:
--- Quote from: thomas on April 06, 2006, 11:53:26 pm ---Ah ok, that is something we'll have to live with then, because I am not using a Windows mutex for portability (only way we could avoid that). wxWidgets mutexes don't work between processes... :(
--- End quote ---
Yeah, bummer about that. :( I got a bit excited when I saw wxMutex in the class list of the wx docs, but then I found out they were local to the process.
I've fixed those two issues. I did some really frantic clicking and opening of multiple instances all at the same time without any issue. Also tested the plugin crash issue and it worked properly.
I'm building the ANSI version now to test on Windows ME and if all goes well, I'll post the diff.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version