From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Caleb Ristvedt Newsgroups: gmane.lisp.guile.user Subject: guile-fibers questions Date: Thu, 30 May 2019 06:32:51 -0500 Message-ID: <87ftowi3do.fsf@cune.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77566"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu May 30 13:33:31 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hWJJK-000K0g-DQ for guile-user@m.gmane.org; Thu, 30 May 2019 13:33:30 +0200 Original-Received: from localhost ([127.0.0.1]:52433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWJJI-0007Ob-St for guile-user@m.gmane.org; Thu, 30 May 2019 07:33:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWJIp-0007OH-S0 for guile-user@gnu.org; Thu, 30 May 2019 07:33:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hWJIo-0005OB-L9 for guile-user@gnu.org; Thu, 30 May 2019 07:32:59 -0400 Original-Received: from mail-it1-x12f.google.com ([2607:f8b0:4864:20::12f]:39107) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hWJIo-0005HN-5n for guile-user@gnu.org; Thu, 30 May 2019 07:32:58 -0400 Original-Received: by mail-it1-x12f.google.com with SMTP id j204so3478451ite.4 for ; Thu, 30 May 2019 04:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cune-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding; bh=RfuQpd5uk/fw0CauW2k1VdWfB2bz5kXnvYqRofC8BoU=; b=hRsvaAL/hEWFKRT0IxwNzdXjnKbRmUhOd9PlgC9gtUzCgY4hgWU367FyKzGAycBWrF MfdhY5An5UrvfjoocSHxe7UjLTjUuQ66dFSPF4BzaX1fbEOfvRGt0CMsproPKyLu36FR r5C1DGuowccIvEeBSd4vbUsrbo4yUX+kTJJQDZzpA7tT8QBf5ChoUZalw6JQcus7qRDp VNVb+ImMcbdPEi1+ZfcjAxNPoVvuiDsp1aMfV1tcfp7nA10DWQI3om0Thu+LK6VoWmxn IRNTV35kcoOrawwQN6cVVOyufeSf6cKByVc9UE5oVXKlo+aW1ffzXbtM5DnnEIpEYcz3 bmJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=RfuQpd5uk/fw0CauW2k1VdWfB2bz5kXnvYqRofC8BoU=; b=GTnKBFI5PhdGJoo+IYHbpk2lgxzryBV/BXvM8AGLQPbVdypyhPjb9gkony+CMcjH1d 668GY29m2xg6qFS5p3tTYg9LYtwbdbC/xm19uBIIXbEFzlOxyWHDn/eexgvW8cNMZB+1 xmkxW520SCYY0ZqUaG5l8RFVSJSPOqJB76BhU+B4RU9Hzo4NqAv2GVjSjS0mvz5yexXY fGf8yxh/9EZmfCia153Uxrr6RtmTYKbvYm10qc0U5adie6jPvyAbEBZRWkg39jyVucSa NKpOlI9EAHlXlv2++rs/BSv2GS38fzgW8c+XY0FhSGGkXZ4yIzmjcUwJDcsLAd9chGHV n7Tg== X-Gm-Message-State: APjAAAXXgoIqXrqFiTHfIopiiCNNYPb6/qhkP33o4wyeaWSPtKNYrBhh Cm7hPr2Q+0TXhdKIDOJ7OrXea/VjwedwfQ== X-Google-Smtp-Source: APXvYqweu/EEOOfcvVclWfoOfudxhdnBit1+CleXl9hY6DTbSUSbbXm0EqQiF8ErpbTVfijWeVj8BQ== X-Received: by 2002:a02:40c8:: with SMTP id n191mr1937991jaa.14.1559215975329; Thu, 30 May 2019 04:32:55 -0700 (PDT) Original-Received: from GuixPotato ([208.89.170.37]) by smtp.gmail.com with ESMTPSA id s10sm768653iob.29.2019.05.30.04.32.54 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 May 2019 04:32:54 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::12f X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15505 Archived-At: (Not sure if this is the right place to ask =C2=AF\_(=E3=83=84)_/=C2=AF) I'm in the position of wanting to use guile-fibers for a server (with the usual "make a new fiber for each new client" pattern), but my "communication with the outside world" goes beyond reading and writing on ports - I actually have to do some synchronization with fcntl file locks. As far as I can tell from reading the epoll(2) man page, there's no simple way to "wait" on acquiring that kind of lock at the same time as waiting for file descriptors to become readable / writable. It's possible to do a nonblocking attempt at acquiring a lock and yield to the scheduler if it fails, then try again next time, but that basically amounts to busy-waiting. The first potential solution I thought of was just creating a new kernel thread for the sole purpose of being blocked and then waking up the fiber and terminating. This could be done easily enough with channels, I imagine, along these lines: -------------------------------------------- (define (acquire-lock lock fd) (let ((acquired-rendezvous (make-channel))) ;; What's the fibers way of specifically creating a new kernel thread? (call-with-new-thread (lambda () ;; should loop in case of EINTR... (put-message acquired-rendezvous (fcntl fd F_SETLKW lock)))) ;; This fiber suspends and the scheduler resumes another fiber while we= wait ;; for above thread to finish (get-message acquired-rendezvous))) -------------------------------------------- But it seems pretty strange to me - kernel threads are supposed to have pretty high overhead to create, too, although I suppose it'd be possible to only resort to creating one if the first nonblocking attempt at acquiring the lock fails. The Fibers manual mentions thread pools as a possible solution - would that involve basically just keeping a pool of these "waiter threads" around instead of terminating them after they finish waiting? Also, I'm a bit confused by the terminology. In particular, I don't really understand what is meant by "scheduler" in the manual. In several places it seems to be synonymous with "kernel thread" (for example, #:parallelism in run-fibers "arranges for a number of peer schedulers to also be created", by default in total current-processor-count). And in the internals interface, make-scheduler apparently returns one object, but once again #:parallelism apparently makes it possible to make multiple? Would this version of the above code be mostly-equivalent? -------------------------------------------- (define (acquire-lock lock fd) (let ((waiter-sched (make-scheduler #:parallelism 1)) (acquired-rendezvous (make-channel))) (spawn-fiber (lambda () ;; should loop on fcntl in case of EINTR... (put-message acquired-rendezvous (fcntl fd F_SETLKW lock))) waiter-sched) (get-message acquired-rendezvous))) -------------------------------------------- Thanks. - reepca