OSDev.org

Which is a good method to handle async requests? Can you give me some advices?

In my old kernel I used threads for requests, which allowed asynchronous execution. The biggest thing you must look out for when using threads is locking resources (such as the mount table) when using them .

I have only few questions:
1 - When a task dies, must I cancel all his requests?
2 - When a task dies, must I clear all his handles?
3 - When a fs is unmounted, must I clear all handles to it?

Do you even want to unmount it when it's being accessed?

Basic software engineering:

1 - What will happen if you don't?
2 - What will happen if you don't?
3 - What will happen if you don't?

In general, what are the consequences of choosing to do it one way or the other?

Just trying to lead you to an answer.

If for example the user take out the cdrom, /media/cdrom must be unmounted and all handles to it must be cancelled. Or not?

Both/neither. If the user takes out the media, and a program still tries to access it, you ask the user to put the media back -- along with a button that says "unmount". If the user hits the "unmount" button -- then you unmount that partition. And let the program deal with an error exit from the "read" function.

so handles mustn't be deleted. So I must check if a handle is valid each time it's used...

Do it however you want. It really isn't that hard. We can't make design decisions for you. You need to make them yourself(this is your OS not ours). like froseph said, what will happen if you don't?

bewing gave you one example of what you could do but you could also simply refuse to let the drive be ejected. However, you could also simply return all errors for the read() function. In addition, you could have a whole subsystem that deals with notifying programs when removable media is ejected.

My point is that there are many ways to handle all the things you asked and there is no right way to do it. No matter what way you chose, it will be right for your OS(albeit it might not be as robust as other ideas but that doesn't make it wrong).