The case of whether default arguments should be used or instead function overloading should be is a topic that isn't so hotly debated anymore. It appears to be a rarer and rarer occurance that default arguments should/can be used.
At least for .NET (not an issue in C#) default arguments should not be used. It's simply a case of when code is compiled against a library the default value is placed in the calling binary. Meaning if a library changes it's default value, the value won't be changed in an assembly using that library until it's recompiled.
Monday, February 13, 2006
Sunday, February 12, 2006
Threading and CORBA
A while back CORBA was all the rage, especially as a means of replacing DCOM. CORBA was to allow seemless integration between machines to share load and allow programs to span multiple machines. Now the only place that really still sees such protocols are those where communication speed between machines is necessary. Protocols such as XML-RPC and SOAP now tend to replace them. These are better simply since they can be more easily debugged by using packet dumps.
I ran across an interesting issue, the other week. One of the guys at work palmed off a problem to me that wasn't mine. The logs showed that a call back was being called out of order and that the program was hanging permantly.
Basically the problem was extremely simple, though to see the behaviour it wasn't. Imagine you have a routine call that is expected to give asynchronous call backs. This means that the callbacks may be returned in any order (i.e. not the other they occurred in and sometimes before the method call has returned). The solution is to simply lock the method so that it can return any required information and then allow the callbacks to run.
The problem is of course since the callbacks occurred out of order, the program was done so that the if the second callback came before the first then it would wait. This was implemented using a changing a thread into a suspend state. Of course this meant that this thread was now unable to complete, and preventing the first callback, or any future callbacks from occurring.
The code has now simply been changed to accumilate all the information from both callbacks and then process it approprately once it's all accumilated. Simple in it's simplicity without any need to worry about threads and their states.
I ran across an interesting issue, the other week. One of the guys at work palmed off a problem to me that wasn't mine. The logs showed that a call back was being called out of order and that the program was hanging permantly.
Basically the problem was extremely simple, though to see the behaviour it wasn't. Imagine you have a routine call that is expected to give asynchronous call backs. This means that the callbacks may be returned in any order (i.e. not the other they occurred in and sometimes before the method call has returned). The solution is to simply lock the method so that it can return any required information and then allow the callbacks to run.
The problem is of course since the callbacks occurred out of order, the program was done so that the if the second callback came before the first then it would wait. This was implemented using a changing a thread into a suspend state. Of course this meant that this thread was now unable to complete, and preventing the first callback, or any future callbacks from occurring.
The code has now simply been changed to accumilate all the information from both callbacks and then process it approprately once it's all accumilated. Simple in it's simplicity without any need to worry about threads and their states.
Subscribe to:
Posts (Atom)