TOPIC:

I still have many problems with correct cleaning up ressources. When analyzing the problems I came accross that already in VO the source code was not always correct (the source code that I had written on my own or that I had collected from different programmers). Here is what I have understood until now:

VO:
- Registeraxit (self) tells the garbage collector that an own method AXIT must be called to clean up additional ressources as file handles, SQL objects, ... that are not standard dynamic memory variables as strings, objects....
- In case that a close method called from the program calls "Unregisteraxit(self)" then the AXIT method does not have to be called anymore because all cleaning has already been made.
- UnregisterAxit in the AXIT method does not make any sense because unregisteraxit should be used to avoid calling AXIT

DOTNET:
- RegisterAxit is not needed, having a destructor (previous AXIT) is sufficient for the runtime to know that there is a method to be called for cleaning.
- The destructor is not similar to the C++-destructor and should only be used if necessary. It should only clean up ressources like file handles, SQL objects.
- the destructor needs additional ressources and prevents cleaning up objects quickly when having to call the destructor. Therefore similar to VO UnregisterAxit(self) or gc.suppressfinalizer(self) can be called in a close method called from the program.
- In contrast to VO the DOTNET garbage collector is called in another program thread parallel to the program execution. This makes the program execution much faster, but can give errors if ressource usage as ODBC is not threadsafe or when accessing global objects.
- Microsoft recommends using the IDISPOSABLE interface for cleaning up ressources. This seems to be mainly for having implementation rules and does not resolve directly correct cleaning up of ressources.

VO and DOTNET:
- Both, VO and Dotnet, have advantages if close methods are called by the programmer if possible: Ressources are released immediately, runtime errors in the close method appear in the normal thread and can be detected easier.
- Both, VO and Dotnet have advantages to limit access to external ressources like files/databases to few program parts and try to handle logical processess only using standard variables as string/objects.

Arne,
I am not sure if there was a question in your message ...
Some remarks:
- In .Net RegisterAxit is not needed. The function in the Vulcan Runtime is empty. DESTRUCTOR (Finalize) is called automatically
- UnRegisterAxit() in .Net calls GC.SuppressFinalize() internally.
- Indeed in .Net the Dispose pattern is recommended. In that case you call GC.SuppressFinalize() in the Dispose method.
- Destructors in .Net are difficult to do right. Ms says about this:
Finalizers are notoriously difficult to implement correctly, primarily because you cannot make certain (normally valid) assumptions about the state of the system during their execution

....

For example, a finalizable object A that has a reference to another finalizable object B cannot reliably use B in A’s finalizer, or vice versa. Finalizers are called in a random order (short of a weak ordering guarantee for critical finalization).

Also, be aware that objects stored in static variables will get collected at certain points during an application domain unload or while exiting the process. Accessing a static variable that refers to a finalizable object (or calling a static method that might use values stored in static variables) might not be safe if Environment.HasShutdownStarted returns true.

See more info on msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx


Robert

Robert,

thank you for answering. I posted this not directly as a question but as a current point of view expecting probable replies because it may be a task also for other programmers.

There is something else what I did not mention directly:
For some of our destructors I see only one possibility that is not recommended by Microsoft: To insert thread locks using the criticalsection functions or the dotnet BEGIN LOCK/END LOCK.

Let's wait and see, I think next week I know if it works, because I have already the test environment that I can let crash the program after about 5 minutes of automated software testing...

Arne,

what I have learned is: do not use destructor! Release/close for example files as soon as possible. Use TRY/CATCH/FINALLY to be sure you close files in the FINALLY block.

Resources, that were left over when an object will be killed, are left over because of program failurs. Catch these and act accordingly.

For my dBase app I have a list of open dbf's. In the top level TRY/CATCH/FINALLY I close the remaining.

There ara many ways to avoid destructor.
Frank

Hi Frank,
you are right. We build most of our code that all critical objects should be destroyed manually. But having 1000 places of code, there will be almost one where it will be forgotten... And it is not easy to find these places: If I register all these objects globally then they are not destroyed. And I have found worse cases: Objects that are destroyed by the GC and that close other objects registered globally in other places. Interesting in how many different places Multithreading can interrupt other code...

Arne

ok, multithreading is not mine. I never tried.
Frank

Yes, that is what you can discover with these complex destructors:
Multihreading is automatically in the Dotnet execution - the Garbage collector runs in another thread, probably even on another processor at the same time that the main program does something else.

But in general: the GC only tries to destroy only objects that are not referenced somewhere. So, as long as you have a reference to them, you have the chance to do things right. So clean them just before you set the variable holding them to NULL. Do something like

DocFile:Close()
DocFile := NULL

As long as you have well designed small classes with well defined life cycle you should not have (much) issues.

As I remember right there are huge source about multithreading in MSDN.
Frank

Yeah ! well designed small classes, where I know what they are doing, I like them also. (Hope that one day we will get rid of the old classes with hundreds of methods with thousands of lines of code calling other untyped classes where noone wants to make many changes anymore)

What's about a refactoring session in cologne on one of these classes?

It is not the know how about refactoring that is missing, it is the time we want to spend on this code. We hope that X# will give us the possibility to run this code with few changes some other years and try to write some better code in the meantime using possibilities we did not have 20 years ago.

I look for something to talk about in a session. And refactoring code that is from me is a challenge for me, you know. That's why I asked for.

Hi Frank,
I believe that refactioring is only partially interesting for the visitors of the cologne conference: In case of trying to reuse as much code as possible that has been written with the dataserver/dbserver/sqltable objects and the VO GUI. And this must be done with the intention to be able to reuse old code and not having to rewrite all code.

Hi Arne,

you're kidding.
Right yesterday a got a bug report. After identifying the module where it occurs I started refactoring. At the end it was an incomplete DO CASE construct where not all possible data constellations were handled. I could not believe, that this situation could ever happen. I'm still surprised. BTW I found another bug there.

Instead of deploying an update, I searched for all remaining DO CASES to change them to SWITCH where possible. I found:
2 places with duplicate CASE blocks. A typical copy/past issue.
3 places with missing OTHERWISE block, so not reporting unusual/unhandled data.
1 uncomplete feature. (Right now a customer sent a mail complaining about. I could answer 'found already, fixed in the next update')

Saying the audience is not interested in refactoring is the same as saying the audience is not interested in delivering bug free high quality software. I really hope that this is not true for the VO/Vulcan/X# community.

I do not say that I'm able to write bug free software. But I'm always interested to find them all before my customers do. I'm doing this by spending a huge amount of time in permanent refactoring. This is as important as writing the initial version.

I see the mountain that shows up when looking to old code. What I want to show is that refactoring is not a rewrite. It's often only rearrange, sort out. It can be done in very small steps whenever you work on old code. And my experience is it's a time saver. On my side and on on my customers side.

Frank

Hi Frank,

I don't think Arne said that refactoring is not important. I'm doing it all the time, but I would never go to a session about refactoring because I think this is not something that can be handled in a session - it needs to be done in everyones code and therefore the proceeding is highly individual.
IMHO people does not go to a session to be convinced - people goes to a session to learn new things or proceedings.

Wolfgang

Yeah, Wolfgang is right. I have been in many of your sessions, Frank, and I liked them. But I cannot use many of the procedures you are using - because of another history and another environment I am working in. It is not easy to make a good session about refactoring and to be close enough to what the users of the cologne conference may need in the next 1 or 2 years.

Hi guys,

We seem to have gone off the original subject heading just a little, unless the 'Garbage Collector' is different to what I thought ;-0) Maybe these forums are GCs !?

On the subject of Frank and any session material, it seems to me that we are focusing our attention on 'refactoring' when in fact we need Frank to show us how to change our coding style from what we used in previous code we wrote - before and after approach.

If we are going to code, and NOT wait two years, I for one need to know how to write my new code so that it is suitable for 'Unit Testing' - and which parts of my code need this treatment. And now that we can do it all in X# he can give me/us all the syntax and tools and ideas to do the job.

For guys in small / medium sized companies, you need to be aware that selling on the company (when owners get to retirement age) means that the quality of the code written has a BIG influence on the sales value of that company. We have a good example of this in the UK and the guys have been working on bringing their app code, and data back-end, up to todays standards - for many years. Yes, its a big job. Like lots of us they started with VO and DBFs which worked very nicely, so why change? The value of their company on the open market was one simple answer.

Another answer was that we all need to change to 'keep up' with the rest of the world.

If it had not been for my local colleagues like Mike Pitcher then I would not be into LINQ and Code First and Entity Framework, or SQL, or WPF. Paul Piko has been a big influence on my changing of what software tools and technology I now use. Thanks Mike and Paul.

Can you all suggest ways and content of what, why, and how, Frank can help bring many of us up to date for new code we write in the next 2 to 3 years ?

Any thoughts and ideas ?
Regards,
Phil.

Hi Phil,

thank you for changing the direction. The thoughts that are always coming in my company if we speak about writing new code:
Should we put all main parts for reading/writing/handling/validating data into Webservices and write only "thin clients" to be more flexible for the future?

Arne

dr philip h. hepburn wrote: Hi guys,
Like lots of us they started with VO and DBFs which worked very nicely, so why change? The value of their company on the open market was one simple answer.

Another answer was that we all need to change to 'keep up' with the rest of the world.

I couldn't agree more.

Additionally (or consequently) if you don't refactor and keep up: productivity slows down and becomes costlier compared to the competition, difficult to attract and keep new employees.

Hi Arne,

We had the same debate a few years back when we decided we couldn't hold off replacing our VO program any longer. Our situation is slightly different, as we've reprogrammed from scratch (in C#, but of course now with X# the principles really are the same).

We've gone for a tiered approach, using WCF in place of traditional web services, but again the principle is the same. It's been completely liberating as far as app development and design goes. Our server modules (which sit behind WCF) are 100% responsible for CRUD operations on the database (SQL Server Express), and simply supply disconnected data to the clients. The client programs don't need to know anything about the db at all, they just deal with collections of objects returned from the WCF services.

In reality, validation needs to be partially handled on the client (basic stuff like x field shouldn't be empty), partly by the db itself (with constraints, unique indexes etc.) and partly in the server modules (eg. where we need to check something in the db before we can confirm and save new or edited data).

By working with a disconnected 'thin' client, you learn to make access to the server more and more abstract and it makes adding or improving functionality very simple. For example you may have a server method that retrieves a list of data from a certain table or view. The server method may have a simple enum as a parameter that defines what the search type should be. So you might start with options to search by name or city in a contact database... In the future you decide you want to add an option to search by postcode, so all you need to do is add a new enum value, and in the server add an extra search condition, and the client will be able to use it immediately without knowing anything about the database.

Again, with a disconnected server you can 'easily' swap back end database, as all you need to modify is the server modules... the interface to the client can stay the same because it holds no reference to the physical db.

The only thing that held us back to begin with was that quite a few of our smaller clients have single programs installed on a single machine, where the server/client model would just be unneeded complexity. But it's very simple to give the option for the client program to call the server dll methods directly, without going through webservices or WCF... so at that point your single install becomes a traditional desktop app. So we ended up with source code with a single compile producing a single set of exe and dlls, which can be installed either on a single machine, on a LAN (with server modules on the LAN server and thin clients on the workstations), or a web server (again with local thin clients).

We could also easily add eg. an ASP.NET type client if we wanted to in the future... server modules would still be the same.

HTH

Nick