OSDev.org

Kevin wrote:Did you forget error handling here? Or are you assuming that you never need to check for errors because the next function would automatically fail, like read() when passed a -1 file descriptor?

You could of course add some kind of conditional execution here. And probably you'll soon find uses for loops (handling short reads maybe). Eventually it might turn out that what you just started to write is a VM.

Sik wrote:To be fair, he did say it wasn't well defined yet. My first thought was that the chain would immediately terminate the moment a call fails. That seems like the obvious approach, especially since errors would be isolated to that chain and wouldn't affect other chains.

Kevin wrote: Yes, coroutines are nice. And no, you don't need your asynchronous syscall interface if the kernel understands them. You already save and restore the register state when processing a syscall, so doing a context switch here comes for free. Even with a synchronous syscall interface, the kernel can just queue the syscall and switch to a different thread/coroutine until the operation has completed. The important part here is that the kernel is working asynchronously internally, but if you want the userspace to feel synchronous, there's little reason to change the traditional syscall interface. Essentially you get something that feels like blocking syscalls, except that they block only a single coroutine instead of the whole thread.

Sik wrote:You know, for all the talk Brendan makes about asynchronicity, he still insists on showing an explicit loop to handle them. Not only that sounds bundersome, it effectively forces the whole thing to become single threaded. If instead of having a loop the system called the callbacks directly, they could be run in separate threads and easily make the system very scalable without even trying - the only thing that would be done sequentially is events that by definition behave that way. In fact, doing things purely asynchronously would remove the need for the scheduler altogether, there isn't task switching, callbacks get called when needed, and the concept of process becomes more about isolation than anything else.

Brendan wrote:Yes, the trivial example is trivial.

Yes, you've failed to extrapolate from that.

Kevin wrote:And if we did want to have parallelism, we would have to add code here that handles replies to requests made within handle_data(). This is quickly becoming a mess. Manually programming global state machines like this doesn't make sense for more than Hello World programs.

Kevin wrote:

Brendan wrote:Yes, the trivial example is trivial.

Apparently not trivial enough that you would actually implement it correctly. And also not trivial enough that it would be as readable as the synchronously written version which does semantically exactly the same.

Kevin wrote:

Yes, you've failed to extrapolate from that.

Oh, yes, I did extrapolate. But you ignored it because you didn't like the result of the extrapolation:

Kevin wrote:And if we did want to have parallelism, we would have to add code here that handles replies to requests made within handle_data(). This is quickly becoming a mess. Manually programming global state machines like this doesn't make sense for more than Hello World programs.

Brendan wrote:I didn't ignore it exactly. The fact is I didn't read your post properly, mostly because I think you're trying your hardest to remain ignorant and I'm wasting my time bothering.

If you had read it, you might notice that the people who disagree with you actually think about what they're saying and that it is you who is demonstrably trying to remain ignorant...

I didn't ignore it exactly. The fact is I didn't read your post properly, mostly because I think you're trying your hardest to remain ignorant and I'm wasting my time bothering.

Yes, you've failed to extrapolate from that.

Oh, yes, I did extrapolate. But you ignored it because you didn't like the result of the extrapolation:

Yes, the trivial example is trivial.

Apparently not trivial enough that you would actually implement it correctly.

Brendan wrote:For optimum data locality you want threads to be explicit. Think like "thread_number_to_send_request = identifier_hash % total_threads;" balancing load between threads, where each thread contains a fraction of the data and that data remains in that thread's CPU's caches.

• optimal time of service for system calls
• optimal memory usage for kernel operations
• reduction of the number and cost of interprocess context switches
• optimal scheduling of user and kernel processes
• optimal throughput in user applications
• stability of the operating system in normal operation
• stability of the operating system under greater than anticipated load
• stability of individual user processes
• securing access to kernel-space data
• securing access to user-space data from kernel space
• securing access to user-space data between user-space processes
• decreasing cognitive load for kernel developers (relevant in both reducing programmer error and allowing more complex software design)
• decreasing cognitive load for application developers

Brendan wrote:I didn't realise there was a "correct" for pseudo-code. The synchronous version isn't extendable in any way that leads to parallelism, and (as I've already explained) I'm not even sure it's possible to make my trivial example equally crippled.

Assume "handle_data()" function is just storing the file's data in memory (or calculating a checksum, or counting how many lines of text are in the file, or....).

When the file has finished loading perhaps a less trivial version of the program breaks out of that message handling loop and starts using a completely different message handling loop (without any of the "no longer needed" file IO stuff) that handles a user interface or something else. This is what I meant earlier when I said "This is like breaking a large finite state machine into a nested "finite state machine of finite state machines"". Sadly, you still think you need a single global state machine as if you never learnt to split complex things into smaller simpler things like most children do, but whatever.

Kevin wrote:

Brendan wrote:I didn't realise there was a "correct" for pseudo-code. The synchronous version isn't extendable in any way that leads to parallelism, and (as I've already explained) I'm not even sure it's possible to make my trivial example equally crippled.

Start another thread running the same code. Voilà, parallelism.

Kevin wrote:

Assume "handle_data()" function is just storing the file's data in memory (or calculating a checksum, or counting how many lines of text are in the file, or....).

In other words, handle_data() is trivial. Maybe you can finally decide whether you want to talk about more complex scenarios or if you don't? Every time I refer to your trivial examples, you say that that's not the real thing, and when I try to think of a real thing, you tell me that I should imagine something trivial instead.

Kevin wrote:

When the file has finished loading perhaps a less trivial version of the program breaks out of that message handling loop and starts using a completely different message handling loop (without any of the "no longer needed" file IO stuff) that handles a user interface or something else. This is what I meant earlier when I said "This is like breaking a large finite state machine into a nested "finite state machine of finite state machines"". Sadly, you still think you need a single global state machine as if you never learnt to split complex things into smaller simpler things like most children do, but whatever.

I just expected that if you're willing to take all the cost of making everything async, you would like to do, you know, two things in parallel. Like loading a file and responding to UI events. At the same time, and not only returning to processing UI events when the file has completed loading.

Kevin wrote:All you've really been showing here so far is that even with asynchronous events and event loops everywhere, you can still build fully synchronous applications.

    createProgressBar();

    for each fileNumber in fileNameArray {
        sendMessage(VFS, OPEN_FILE_REQUEST, fileDetailsArray[fileNumber].name);
    }

    do {
        if(stillCalculating) {
            while( stillCalculating && (getMessageWithTimeout(0) == TIMEOUT) ) {
                stillCalculating = doSomeCalculations();
            }
        } else {
            getMessage(0);
        }
        switch(message.type) {
            case PARENT_TERMINATED:
            case TERMINATE:
                exit();
                break;
            case GUI_BUTTON_CLICK:
                switch(message.buttonID) {
                    case PROGRESSBAR_CANCEL:
                        exit();
                        break;
                    case PROGRESSBAR_HELP:
                        if(!helpShowing) {
                            createHelpDialogBox();
                            helpShowing = true;
                        }
                        break;
                    case HELP_CLOSED:
                        helpShowing = false;
                        break;
                }
                break;
            case OPEN_FILE_REPLY:
                if(message.status != OK) exit();
                fileNumber = message.fileNumber;
                fileDetailsArray[fileNumber].fileSize = message.fileSize;
                sendMessage(VFS, READ_FILE_REQUEST, fileNumber, 0);
                break;
            case READ_FILE_REPLY:
                if(message.status != OK) exit();
                handleData();
                if(fileDetailsArray[fileNumber].filePos < fileDetailsArray[fileNumber].fileSize) {
                    sendMessage(VFS, READ_FILE_REQUEST, fileNumber, fileDetailsArray[fileNumber].filePos);
                } else {
                    sendMessage(VFS, CLOSE_FILE_REQUEST, fileNumber);
                    readFiles++;
                    redrawProgressBar();
                }
                break;
            case CLOSE_FILE_REPLY:
                break;
        }
    } while(readFiles < totalFiles);
    destroyProgressBar();

Brendan wrote:

Kevin wrote:

Brendan wrote:I didn't realise there was a "correct" for pseudo-code. The synchronous version isn't extendable in any way that leads to parallelism, and (as I've already explained) I'm not even sure it's possible to make my trivial example equally crippled.

Start another thread running the same code. Voilà, parallelism.

Unless you have an actual reason to want another thread (e.g. different priority work, needing another CPU); additional threads add more bloat for nothing (memory for stack, thread specific storage, message queues; thread switches between the thread you could've used and the unnecessary thread/s, etc).

Kevin wrote:In other words, handle_data() is trivial. Maybe you can finally decide whether you want to talk about more complex scenarios or if you don't? Every time I refer to your trivial examples, you say that that's not the real thing, and when I try to think of a real thing, you tell me that I should imagine something trivial instead.

No, you're trying so hard to learn nothing that you don't notice things like "or calculating a checksum, or counting how many lines of text are in the file, or...." (above).

Sure - I don't really want to create a more elaborate example because I know you're going to waste my time nitpicking irrelevant details if I do.

Against my better judgement: [...]

func process_file(filename)                                                                            
{                                                                                                      
    ret = vfs_open_file(filename, &fd, &fileSize);                                                     
    if (ret != OK)
        exit();                                                                                        
                                                                                                       
    filepos = 0;                                                                                       
    do {
        ret = vfs_read_file(fd, filePos);
        if (ret != OK)
            exit();                                                                                    
        handleData();                                                                                  
    } while(filePos < fileSize);                                                                       
    
    vfs_close_file(fd);
    readFiles++;
    redrawProgressBar();                                                                               
}           
            
func calculation()
{           
    while (doSomeCalculations());
}                   
                    
func progressbar_cancel()
{                   
    exit();             
}                       
                    
func progressbar_help()
{               
    static helpShowing = false; 
    if (!helpShowing) {
        helpShowing = true;                                                                            
        helpDialogBox();                                                                               
        helpShowing = false;
    }       
}           
            
createProgressBar();
register_callback(GUI_BUTTON_CLICK, PROGRESSBAR_CANCEL, progressbar_cancel);                           
register_popup_thread(GUI_BUTTON_CLICK, PROGRESSBAR_HELP, progressbar_help);                           
            
for each fileNumber in fileNameArray {                                                                 
    thread_create(process_file, fileDetailsArray[fileNumber].name);
}           
thread_create(calculation);
                
while (readFiles < totalFiles) {
    /* Wait for event (including "thread exit") and run registered handler */                          
    mainLoop();
}       
            
destroyProgressBar();

Kevin wrote:I'm not sure if you will consider it nitpicking, but the most important finding for me in this piece of code is that you still have a single global event loop. Not because the calculation, the help dialog and processing the file were so tightly coupled - they are almost completely independent and the only common thing is that they are running at the same time - but because you have to in order to keep them running at the same time. There is no way to use your "state machine of state machines" here to simplify things.

Kevin wrote:For comparison, written with a threaded model, this needs almost exactly the same number of lines, but I would consider it much more readable and easier to understand because you get a lot more locality:

Brendan wrote:Of course if you wanted to waste your time making it slower, you could build a generic "callback manager" on top (e.g. where you have one function to register a callback and another to discard/delete a previously registered callback), and never (explicitly) deal with a message handling loop after that.

Brendan wrote:Except now it's inefficient because of all the pointless threads and excessive thread switching. Worse, now you're going to need to deal with concurrency control (locks, mutexes, etc) for everything mutable that's shared between threads, and for anything non-trivial getting the concurrency control right is going to be far more painful (and error-prone, in a "heisenbug" way) than "state machine" ever was.

Sik wrote:Actually the part about buffering syscalls here would be useful, software would not expect them to work immediately due to the async nature, and buffering them like that would allow for multiple syscalls to be queued up to be sent all at once (reducing the switching).