From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 3EF64BC6C for ; Wed, 6 Feb 2008 09:56:47 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACoFqUfRVY6/hmdsb2JhbACQMgEBAQcFBAIHChaBF5U4hmM X-IronPort-AV: E=Sophos;i="4.25,311,1199660400"; d="scan'208";a="7691773" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Feb 2008 09:56:47 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m168ua7n026325 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 6 Feb 2008 09:56:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACoFqUfRVY6/hmdsb2JhbACQMgEBAQcFBAIHChaBF5U4hmM X-IronPort-AV: E=Sophos;i="4.25,311,1199660400"; d="scan'208";a="7691771" Received: from ti-out-0910.google.com ([209.85.142.191]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Feb 2008 09:56:45 +0100 Received: by ti-out-0910.google.com with SMTP id b8so154285tic.9 for ; Wed, 06 Feb 2008 00:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ZPHUannO9KPczk2S4ba+WbowxdKUQBWbk1mQuwZYSKo=; b=PvDDrgp3QRKgDuTi2Ijq/Ztwz95Bf5V9KRA+/FfB67/sAdLC3vJ/N5TVOzmIr1EC4HO05/TrjMGC1E0As30yzw/YsZmo+8SieGyji5SNVLHVSL5oKu/HS7XHcGSar0mvQqK7yT+YoubDis2U4StST+/73UM12ynm/BvsIB3Llqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a/2FpJR+lKC5DPou9vXKk9tQZim+jerSjcT5tSWu19MrnAmrhUXNaTfn1bpd8zSRf+ChaoyW/vtx71ynk+mSfV2BmrpXAoFeRdz6nHIHlhpfiB2GiFy7Jsst8jDSIEfXTuUcSqVpJEO5AXW2vDPNDCAwnUvIDxiyfshqwa42qjQ= Received: by 10.110.53.11 with SMTP id b11mr4711940tia.57.1202288203818; Wed, 06 Feb 2008 00:56:43 -0800 (PST) Received: by 10.110.26.14 with HTTP; Wed, 6 Feb 2008 00:56:43 -0800 (PST) Message-ID: <90823c940802060056i6afd360did9cbef43c9664bf@mail.gmail.com> Date: Wed, 6 Feb 2008 11:56:43 +0300 From: "Dmitry Bely" To: "Alain Frisch" Subject: Re: [Caml-list] Ocaml debugger under Windows Cc: ocaml In-Reply-To: <47A8CE81.5040905@frisch.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <90823c940802050146u7cac0aape4e72b4fc6a3089@mail.gmail.com> <47A83251.7010306@frisch.fr> <90823c940802050923h77a95192gdabcd9c0807dccd6@mail.gmail.com> <9b415f950802050940m2f49137by41a32ba77b564e09@mail.gmail.com> <90823c940802051139k3001a0cehec5408046832c187@mail.gmail.com> <47A8CE81.5040905@frisch.fr> X-Miltered: at discorde with ID 47A97644.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 debugger:01 frisch:01 frisch:01 cygwin:01 sockets:01 gdb:01 abstraction:01 sockets:01 gdb:01 readfds:01 writefds:01 exceptfds:01 struct:01 timeval:01 On Feb 6, 2008 12:00 AM, Alain Frisch wrote: > > I don't think it would work on Windows. You cannot select() on > > arbitrary Unix.file_descr - only socket-associated descriptor can be > > used. > > Do you know how Cygwin emulate the desired behavior? Does it use threads? It surely use WaitForMultipleObjects() instead of select(). The implementation is quite complicated; GDB's one seems to be better showing an idea (see below). But frankly speaking I don't like to add any C code here - in fact it means altering win32unix library that is unlikely to happen. Can it be solved on Caml level? Anyone? Is select() with small timeout is acceptable? /* Wrapper for select. On Windows systems, where the select interface only works for sockets, this uses the GDB serial abstraction to handle sockets, consoles, pipes, and serial ports. The arguments to this function are the same as the traditional arguments to select on POSIX platforms. */ int gdb_select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) { static HANDLE never_handle; HANDLE handles[MAXIMUM_WAIT_OBJECTS]; HANDLE h; DWORD event; DWORD num_handles; int fd; int num_ready; int indx; num_ready = 0; num_handles = 0; for (fd = 0; fd < n; ++fd) { HANDLE read = NULL, except = NULL; struct serial *scb; /* There is no support yet for WRITEFDS. At present, this isn't used by GDB -- but we do not want to silently ignore WRITEFDS if something starts using it. */ gdb_assert (!writefds || !FD_ISSET (fd, writefds)); if ((!readfds || !FD_ISSET (fd, readfds)) && (!exceptfds || !FD_ISSET (fd, exceptfds))) continue; h = (HANDLE) _get_osfhandle (fd); scb = serial_for_fd (fd); if (scb) serial_wait_handle (scb, &read, &except); if (read == NULL) read = h; if (except == NULL) { if (!never_handle) never_handle = CreateEvent (0, FALSE, FALSE, 0); except = never_handle; } if (readfds && FD_ISSET (fd, readfds)) { gdb_assert (num_handles < MAXIMUM_WAIT_OBJECTS); handles[num_handles++] = read; } if (exceptfds && FD_ISSET (fd, exceptfds)) { gdb_assert (num_handles < MAXIMUM_WAIT_OBJECTS); handles[num_handles++] = except; } } /* If we don't need to wait for any handles, we are done. */ if (!num_handles) { if (timeout) Sleep (timeout->tv_sec * 1000 + timeout->tv_usec / 1000); return 0; } event = WaitForMultipleObjects (num_handles, handles, FALSE, timeout ? (timeout->tv_sec * 1000 + timeout->tv_usec / 1000) : INFINITE); /* EVENT can only be a value in the WAIT_ABANDONED_0 range if the HANDLES included an abandoned mutex. Since GDB doesn't use mutexes, that should never occur. */ gdb_assert (!(WAIT_ABANDONED_0 <= event && event < WAIT_ABANDONED_0 + num_handles)); if (event == WAIT_FAILED) return -1; if (event == WAIT_TIMEOUT) return 0; /* Run through the READFDS, clearing bits corresponding to descriptors for which input is unavailable. */ h = handles[event - WAIT_OBJECT_0]; for (fd = 0, indx = 0; fd < n; ++fd) { HANDLE fd_h; struct serial *scb; if ((!readfds || !FD_ISSET (fd, readfds)) && (!exceptfds || !FD_ISSET (fd, exceptfds))) continue; if (readfds && FD_ISSET (fd, readfds)) { fd_h = handles[indx++]; /* This handle might be ready, even though it wasn't the handle returned by WaitForMultipleObjects. */ if (fd_h != h && WaitForSingleObject (fd_h, 0) != WAIT_OBJECT_0) FD_CLR (fd, readfds); else num_ready++; } if (exceptfds && FD_ISSET (fd, exceptfds)) { fd_h = handles[indx++]; /* This handle might be ready, even though it wasn't the handle returned by WaitForMultipleObjects. */ if (fd_h != h && WaitForSingleObject (fd_h, 0) != WAIT_OBJECT_0) FD_CLR (fd, exceptfds); else num_ready++; } /* We created at least one event handle for this fd. Let the device know we are finished with it. */ scb = serial_for_fd (fd); if (scb) serial_done_wait_handle (scb); } return num_ready; } - Dmitry Bely