Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #89908

Re: Manipulating C code at the AST level, in C

Show all headers | View raw

On 15/08/2026 12:07, Jim Jackson wrote:
> On 2026-08-15, c186282 <c186282@nnada.net> wrote:
>> On 8/14/26 07:26, Nuno Silva wrote:
>>> (Given I'm commenting on the content of the online manual on a Linux
>>> system, I'm adding and followingup-to comp.os.linux.misc.)
>>>
>>> On 2026-08-11, Lawrence D???Oliveiro wrote:
>>>
>>>> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>>>>
>>>>> For select (called unix-fast-select in SBCL), see sb-unix.
>>>>
>>>> select(2) is considered an archaic way of doing things these days,
>>>> because of its ABI limitations. The modern way is poll()
>>>> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
>>>> <https://manpages.debian.org/epoll(7)> (Linux-specific).
>>>
>>> The online manual here (a GNU/Linux system) says:
>>>
>>>       "poll, ppoll - wait for some event on a file descriptor"
>>>
>>> Perhaps that should be rewritten. Reading further, it's not singular,
>>> but that description with "*A* file descriptor" does make it sound like
>>> poll is not a suitable replacement for select.
>>
>>
>>     Polling, for this sort of thing, has to be
>>     fast and constant - a big CPU drag. You are
>>     basically WAITING for something to happen -
>>     which MAY or may NOT happen at any moment.
> 
> Despite the names, these functions WAIT for events.
> Yes it could be sort of confusing.
> 
Normal mechanism would be to put the calling thread into suspense, and 
trigger a resume by setting a flag from interrupt. The thread then 
'resumes' and checks to see why it was woken up.

AFAICT from a cursory glance there is no difference between select and 
poll 'under the hood'.

They just present themselves differently


-- 
Civilization exists by geological consent, subject to change without notice.
  – Will Durant

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Manipulating C code at the AST level, in C Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-14 12:26 +0100
  Re: Manipulating C code at the AST level, in C Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-14 13:53 +0100
    Re: Manipulating C code at the AST level, in C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 21:10 +0000
  Re: Manipulating C code at the AST level, in C scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 16:00 +0000
  Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-14 23:47 -0400
    Re: Manipulating C code at the AST level, in C rbowman <bowman@montana.com> - 2026-08-15 07:20 +0000
      Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-15 11:33 +0100
      Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-15 22:41 -0400
        Re: Manipulating C code at the AST level, in C "Carlos E. R." <robin_listas@es.invalid> - 2026-08-16 10:50 +0200
    Re: Manipulating C code at the AST level, in C Jim Jackson <jj@franjam.org.uk> - 2026-08-15 11:07 +0000
      Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-15 12:18 +0100
    Re: Manipulating C code at the AST level, in C Richard Kettlewell <invalid@invalid.invalid> - 2026-08-15 12:20 +0100
      Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-16 02:09 -0400
        Re: Manipulating C code at the AST level, in C Richard Kettlewell <invalid@invalid.invalid> - 2026-08-16 09:59 +0100
          Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-16 11:42 +0100

csiph-web