• Re: C90+ fselect()

    From Lawrence =?iso-8859-13?q?D=FFOlivei@3:633/10 to Paul Edwards on Thu Sep 18 06:40:33 2025
    From: ldo@nz.invalid

    On Thu, 18 Sep 2025 13:55:16 +0800, Paul Edwards wrote:

    And obviously if it's a POSIX system, it can do a select() on the
    file numbers ...

    select(2) is an antiquated way of doing it. Use poll(2) or epoll(7).

    <https://manpages.debian.org/poll(2)>
    <https://manpages.debian.org/epoll(7)>

    --- SoupGate-Linux v1.05
    * Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)
  • From Richard Tobin@3:633/10 to Paul Edwards on Thu Sep 18 11:01:05 2025
    From: richard@cogsci.ed.ac.uk

    In article <10ag6sc$3m3q1$1@dont-email.me>,
    Paul Edwards <mutazilah@gmail.com> wrote:

    parmnumber = fselect(stdin, comm_fp, NULL);

    I remember writing an fselect() back in the 1980s.

    A problem with replicating select() at the FILE level is the buffering
    within standard i/o system. The obvious solution is for fselect() to
    return immediately if any data is already buffered for any of the
    FILEs. That's not ideal because whether standard i/o input functions
    block depends on the data itself. Suppose the single character "1"
    was buffered, then fgetc() would succeed immediately, but fgets()
    would block. All you could really guarantee is that a single fgetc()
    would return immediately.

    -- Richard

    --- SoupGate-Linux v1.05
    * Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)
  • From Lawrence =?iso-8859-13?q?D=FFOlivei@3:633/10 to Richard Tobin on Thu Sep 18 21:29:41 2025
    From: ldo@nz.invalid

    On Thu, 18 Sep 2025 11:01:05 -0000 (UTC), Richard Tobin wrote:

    A problem with replicating select() at the FILE level is the buffering
    within standard i/o system.

    Not clear why you feel the need to mix the two.

    --- SoupGate-Linux v1.05
    * Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)