Elias Mårtenson <address@hidden> writes:
Hi Elias,
> But if the user really fires off 250 threads, then it makes sense that
> they get that many frames. After all, this is a computer and they are
> supposed to do what you tell them to do.
Why? I don't see a reason to get a new frame for a thread.
I don't think we're in disagreement actually. I was referring to the specific case where a thread explicitly creates a frame. If you were to fire off 250 of ‘create-a-new-frame’ threads, you'd expect to have 250 frames created.
But who would run 250 ‘create-new-frame’ calls at all, threads or no threads?
> Imagine if you're typing in a buffer and you're writing a word that
> has the letter y in it. As you are about to insert the y into the
> buffer, a background thread asks "are you sure you want to delete all
> your files?".
I haven't proposed ever such a scenario. User input is a critical
section in a thread. Once a prompt appears in a minibuffer, the focus of
user input must be changed to another thread untilthe complete input is
read
You mean, the focus must be manually shifted from the active buffer to the minibuffer? If so, then that sounds good.
This reminds me of a book I recently read, “The Apollo Guidance Computer — Architecture and Operation”. In it, they describe how the user interface worked on the limited hardware which had 3 main 50digit numeric input fields, a few smaller numeric fields and 14 or so buttons. They had an indicator light labelled KEY REL (“key release”) that indicated that a background job required operator attention. Pressing a similarly labelled button switched the display to that of the waiting task).
It seems as though some of these same questions were being asked back in the 60's. :-)
Regards,
Elias
