static destructors? why?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Habbit

static destructors? why?

Post by Habbit »

First of all: hi everyone!! this is my first post here as an OSdever!! ;D

Ahem... The question: I have been reading this forum and the wiki for a long time, and I have always been intrigued by a part of the "Doing a kernel in C++" page. It states that static and global objects need their constructors to be called prior to entering C++ land, which makes sense. The explanation about how to make ld insert a list of constructors for us is very good, but it also talks about those objects' destructors.

I don't know if I'm asking something obvious, but this got me baffled... Why would you run a destructor AFTER your kernel?? First, your kernel should never exit, but even if it does (because a strange unhandled error not leading to either a panic or a triple fault), what's the point on running destructors then? The only thing that makes sense to me after a kernel exiting that way is "cli; hlt" to avoid further damage. Am I just plain stupid for not seeing the importance of this or what?
viral

Re:static destructors? why?

Post by viral »

hello..
Why would you run a destructor AFTER your kernel??
And that's why I have removed that destructor stub from my kernel. Even I dont see any use of it.
Kemp

Re:static destructors? why?

Post by Kemp »

I think it's more for completeness and standard code than being actually useful.
B.E

Re:static destructors? why?

Post by B.E »

As I have never use C++ in OS Deving, The only thing that I can see, is to shutdown hardware like video, hardrives and soundcard. It also may be used for writting buffers to disk.
Habbit

Re:static destructors? why?

Post by Habbit »

B.E wrote: As I have never use C++ in OS Deving, The only thing that I can see, is to shutdown hardware like video, hardrives and soundcard. It also may be used for writting buffers to disk.
Well I think you would better do that INSIDE your kernel (with exception handling, memory management, etc), or even from userspace if you think microkernel, than AFTER it.
spider

Re:static destructors? why?

Post by spider »

I would have to agree with B.E on this one. It would be used just like you would in any other c++ program to clean up after your self. But since the kernel never shutdown so to say. Unless something bad happens then it would still be nice to free all the resources the kernel has. Or if the user shutdown the computer then its a good idea to also free everything you have. IT could be done with other functions but why write the other functions to clean up after your self when c++ has a built in function for you?
Kemp

Re:static destructors? why?

Post by Kemp »

But you don't really need to clean anything up after yourself, as it's all gone as soon as the power goes off anyway :P Anything that actually needs to be done should be done by the relevant subsystem (such as a driver when it is exited) and even that often won't be strictly necessary. I can't think of anything the kernel itself handles that should need anything special done with it on shutdown.
spider

Re:static destructors? why?

Post by spider »

There probly isnt anything, but some wierd system design might have something. Doesn linux and windows need to clean up after them self when you shut them down? If they dont why can it harm your system when you just press the off button on your system. (Im talking from experience here, i done that on linux and destroyed one of my harddrives) So that says to me there is something that need to be cleaned up after your self when the system shutdown.
Habbit

Re:static destructors? why?

Post by Habbit »

spider wrote: So that says to me there is something that need to be cleaned up after your self when the system shutdown.
Of course many things need to be cleaned up after shutting the computer down, but what I'm trying to state here is that none of those should
1) be used as global/static objects, which usually are trivial things such as kout
2) de-initialized _after_ kernel has exited, with probably no int/exc control, no memory management, etc.

BTW, i will clarify myself: I am talking about a C++ kernel that is started like this:

Code: Select all

start: # GRUB jumps here, we have PMODE32+A20
    cli # No interrupts 'til we have an IDT
    ... # Set some things up (GDT, basic paging for higher half...)
    call _staticConstructors # C/ASM function
    call kmain # C++ function <--- THIS IS WHAT I CALL "kernel"
    call _staticDestructors # C/ASM: i see no point in THIS one
    # Just for the sake of it, make sure we don't run into bogus mem if the kernel ever exits
    cli # kmain has probably enabled ints. Clear them...
    hlt # ...and halt forever
The point I'm trying to make is that the "_staticDestructors" function WILL NEVER BE CALLED because whatever the kernel does, it should do within the call to "kmain". Even shutting down the system is done from within kmain (i.e., through an APM function, I have no idea about that). Doing something after the kernel exits makes no sense because, by definition, the kernel never exits (or so I think, correct me if I'm wrong)
DruG5t0r3

Re:static destructors? why?

Post by DruG5t0r3 »

A destructor can do many things....like send a notice over email that the system has shutdown to unmounting a hard drive etc....not just memory related. Of course I understand the point that you don't really need to clear up memory since its going to get cleaned up pretty well as soon as it shuts down but many other things can be done.
bluecode

Re:static destructors? why?

Post by bluecode »

DruG5t0r3 wrote:A destructor can do many things....like send a notice over email that the system has shutdown to unmounting a hard drive etc.
Sending emails in a destructor is a pretty bad idea, because it depends on other parts of the system and these might already be shut down. I would not do anything, that depends on another static/global class, in a con/destructor (except your are damn sure what your doing).
But generally I would say you should just use the C++ features you feal comfortable with. If you don't like destructors (in the kernel), then just don't use them.
But I think it's worth mentioning in the faq how con/destruction works, because you also might want to build that into user space C++ library (And don't tell us, you don't need them there ;) ).
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:static destructors? why?

Post by Solar »

Kemp and spider nailed it: It's for completeness and cleanliness rather than any particular "purpose". If you don't like it, remove it.
Every good solution is obvious once you've found it.
Kemp

Re:static destructors? why?

Post by Kemp »

I think the problem here comes from people thinking about what is happening wrong. These destructors aren't the things that would be called (for instance) when Windows is shutting down, or even when it displays the "It is now safe to turn off your computer" screen, they would be called after the kernel stops running (well, during it stopping running, but that's just nit-picking :P), which would be somewhere around just after the time you hit the power button. Note that while the aforementioned "safe" screen is being displayed the kernel is still running, it's just sitting there in a halt loop usually. I'd like to see anything run after the power goes off ;D
evincarofautumn

Re:static destructors? why?

Post by evincarofautumn »

So why don't you just let your [tt]kmain[/tt] fall off the end of itself (i.e. [tt]return[/tt] to the asm bit) so that your destructors can be called? After destruction is where you would insert your shutdown, i.e.

Code: Select all

start:
    cli
    ...
    call    _staticConstructors     ; ctors
    call    kmain                    ; kernel
    call    _staticDestructors       ; dtors
    call    shutdown                 ; system shutdown call (if available)
    cli                             ; just in case
    hlt
I assume this would work. It's also pretty dang pleasing; just because you can omit the destruction of your global objects (of which there should be few, anyway) doesn't mean that you should, because there might (not probably) be consequences somewhere down the line.
Post Reply