From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 11 Jun 2009 15:54:51 +0100 From: Eris Discordia To: 9fans@9fans.net Message-ID: <47FB4BC290D45EE2F6D427EB@[192.168.1.2]> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 095960dc-ead5-11e9-9d60-3106f5b1d025 > the signal context is the original calling thread. unless > ms' diagram is incorrect, this is a single threaded operation; > only the i/o originator can process the event. so the plan 9 Of course it is single-threaded operation. That's the very idea behind=20 using callbacks. Originally they were used to allow applications to do=20 asynchronous I/O on earlier Windows incarnations that had no concept of=20 threading. When threading became available it was correctly considered=20 hazardous, as with any other form of concurrency, so it was and is avoided=20 unless absolutely necessary. Callbacks survived the introduction of=20 threading. There are actually three thinkable options here: read-and-wait=20 (synchronous), subscribe-and-continue (asynchronous using callback), and=20 continue-until-notified (asynchronous using message queue). My point was=20 that as of some time ago, more than a decade I believe, Windows began=20 offering all three options which may be used on their own or in tandem. The = three options can be sorted in order of increasing initial cost: callback,=20 message queue, thread (and/or "lightweight process"). Average cost reverses = that ordering. The application determines which strategy is better. On the subject of who gets to process a certain event on Windows it should=20 be noted that any process/thread that subscribes for an event will be=20 notified, if an opportunity for subscription is provided in the first=20 place. In case of a read other processes/threads have no notion that a=20 specific read has been requested and they will never want to process the=20 results of a read they haven't requested. Interface and other events that=20 may concern more than one process/thread, on the other hand, can be=20 processed by any worker that opts to process them. A chain of handlers with = varying priorities is very easy to construct within this framework. > there's plenty of overlapped i/o in plan 9 =E2=80=94 it's in the > disk and network device drivers. even stripping away > the register fiddling, it's not an i/o model that's attractive; > that's the reason all the details are hidden in the kernel. I might as well repeat myself: choice of strategy depends on the=20 application. Given choice programmers can decide on which strategy or=20 combination of strategies works best. Without choice, well, they will just=20 live with what's available. It is common with Windows programmers to use a=20 combination of threading, callbacks, and synchronous I/O that best=20 represents the application's workings. GUI is often run in its own thread=20 which is made to wait only on I/O that crucially affects future=20 interactions, e.g. a user "Open File" request. Processing of sporadic=20 network events, e.g. reports from a network resource, is done in auxiliary=20 message queues. Light network operations are delegated to a single thread=20 that uses callbacks. Only heavy network operations are aggressively=20 threaded. Most notable here is the fact that allowing for various compatible options=20 to grow within the same system can only enrich it while insisting on "The=20 One Right Way" always leaves open the question of whether a different=20 choice of strategy on the same platform, were a different choice available, = would have yielded better results. > are you saying the author(s) had their windows blinders on > and might not have considered other options? I believe at this point it is clear that all thinkable options are=20 available on the platform you refer to as (horse) "blinders" but that=20 really isn't important. The author(s) had criticized a specific I/O model=20 without mentioning, or probably even knowing, that alternatives existed and = could be profiled for tangible, definitive results. I merely pointed that=20 out. --On Thursday, June 11, 2009 08:16 -0400 erik quanstrom=20 wrote: > On Thu Jun 11 04:12:13 EDT 2009, eris.discordia@gmail.com wrote: >> > i don't think i understand what you're getting at. >> > it could be that the blog was getting at the fact that select >> > funnels a bunch of independent i/o down to one process. >> > it's an effective technique when (a) threads are not available >> > and (b) processing is very fast. >> >> This might help: what he is getting at is probably the question of why >> not make possible network applications that consist of a bunch of >> callbacks or a mix of callbacks and listener/worker threads. Windows >> implements both synchronous and asynchronous I/O. Threads are >> available. Callbacks, too, as well as message queues. > > are you saying the author(s) had their windows blinders on > and might not have considered other options? > > my windows-fu is very low. but according to microsoft > http://msdn.microsoft.com/en-us/library/aa365683(VS.85).aspx > windows "asynchronous" (overlapped) i/o signals the calling thread, so > the signal context is the original calling thread. unless > ms' diagram is incorrect, this is a single threaded operation; > only the i/o originator can process the event. so the plan 9 > model would seem to me to be better threaded and i think > the CSP-style of the plan 9 model makes it easier to > reason about. and has already been implemented under > unix without changing the kernel. see p9p. > >> Ideally, it is the programmer's informed choice >> based on their understanding of their application's priorities whether >> to use callbacks, listener/worker threads, message queues, or a >> combination. Someone may find it worth the effort to compare these >> approaches on a platform that provides both. (COM is notorious for >> implementing things through callback that get some wrapping of one's >> head around them before making sense.) > > there's plenty of overlapped i/o in plan 9 =E2=80=94 it's in the > disk and network device drivers. even stripping away > the register fiddling, it's not an i/o model that's attractive; > that's the reason all the details are hidden in the kernel. > > - erik