From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1533431e7e9d2eb X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: Nontrivial examples of C interface with Ada Date: 2000/05/25 Message-ID: #1/1 X-Deja-AN: 627361947 References: <8gk6ee$ti8$1@nnrp1.deja.com> X-Complaints-To: abuse@pacbell.net X-Trace: news.pacbell.net 959295267 206.170.2.177 (Thu, 25 May 2000 15:54:27 PDT) Organization: SBC Internet Services NNTP-Posting-Date: Thu, 25 May 2000 15:54:27 PDT Newsgroups: comp.lang.ada Date: 2000-05-25T00:00:00+00:00 List-Id: > > blocking sockets, with asynchrony being provided by suitable Ada tasking. > > Ugh! That's exactly the kind of heavy solution to a simple problem that If it's good enough for Java or Windows CE .... ;) Are we thinking about the same thing for "non-blocking sockets"? I'm talking about the kind (in Windows) where you get an "interrupt" (well, a message in the Windows message loop, ie, good old Windows 3.1's version of multitasking) when data arrives, or the socket disconnects, etc. If you just mean something like "read data, and let me do occasional status tests when convenient to see when it's present and my program can process the data", you don't need extra tasks for that. You just use what I would call a blocking socket, and interrogate status to see if there's data available to read. > But for that escape hatch to be of any use, you need thin Ada bindings! Well, clearly, thick bindings must be built on top of thin ones. Nobody has suggested a way to make a thick binding without having a thin one underneath.