5 ms·

It's pretty ludicrous to alias select since it's the sort of thing you're likely to be calling in a concurrent program.

kazinator 7y ago
It's not really the sort of thing you'd use in a modern concurrent program. There is no reason to use select on a system where you have poll. As of 2001, POSIX moved select into its own header, so you shouldn't be getting a declaration of it any more from <sys/time.h>. libmill provides some wrapping for polling mechanisms; you'd probably be going through that in libmill-based sources. The clash, if it happens, has very easy, localized workarounds. Note that the library has a macro called end, which is a very common identifier in programs. Why didn't the author consider that a problem, but switched Go's select to choose?
- legohead 7y ago
  select is super well known in C, as I'm sure you're aware. I have over 20 years in it myself. sure, workarounds are easy, but that's not the point. your suggestion that it should be named the same as Go is a bit ridiculous. why is that even important? what is important is potentially confusing developers, and adding a new "select" into C would do just that. the only mistake is Go using the word select to begin with.
  - kazinator 7y ago
    select isn't in C; it's in POSIX. I worked in Windows development shops where nobody knew select; but they could write WaitForMultipleObjects code in their sleep. A strictly conforming ISO C program can use the select identifier however it wants, including as an external name for an object or function. > your suggestion that it should be named the same as Go is a bit ridiculous It's not any more ridiculous than wanting to have a library which imitates Go concurrency down to macros that imitate some of the syntax.
    - xeeeeeeeeeeenu 7y ago
      >I worked in Windows development shops where nobody knew select; but they could write WaitForMultipleObjects code in their sleep. That's hard to believe considering the fact that POSIX-compatible select() is a part of the winsock API.
  - geezerjay 7y ago
    > your suggestion that it should be named the same as Go is a bit ridiculous. Are you aware that you're making that complaint in a discussion on Libmill: Go-Style Concurrency in C? It's one thing to skip the submission to jump to the comment section. It's an entirely different thing to start mindlessly criticizing constructive criticism presented by fellow users while being entirely oblivious to both the subject and the context. That's just noise, and contributes zero to the discussion. In fact, it takes an awful lot from it.
    - fao_ 7y ago
      > Are you aware that you're making that complaint in a discussion on Libmill: Go-Style Concurrency in C? Just because it's Go-style, doesn't mean "Exactly like Go, down to the keywords used".
      - geezerjay 7y ago
        > Just because it's Go-style, doesn't mean "Exactly like Go, down to the keywords used". That point was already discussed previously in the discussion, and it's pointless to continue repeating what has already been said, particularly when those arguments boil down to nothing more than a personal opinion.
        fao_ 7y ago
        I read the entire discussion and didn't see a single person mention it, but ok.
newnewpdro 7y ago
While I agree it's poor form to reuse the word 'select' for obvious reasons, there are few circumstances where it makes sense to use the select() interface in any new programs. It's a very common source of hidden bugs thanks to FD_SETSIZE.
- kazinator 7y ago
  It also performs badly due to to all the bitmask twiddling, and copying of those bitmasks to the kernel and back. If you want to select on file descriptor 1000, the bitmask has to include zeros for descriptors 0 through 999. Those get copied to the kernel and iterated over dutifully.

It's not really the sort of thing you'd use in a modern concurrent program. There is no reason to use select on a system where you have poll. As of 2001, POSIX moved select into its own header, so you shouldn't be getting a declaration of it any more from <sys/time.h>. libmill provides some wrapping for polling mechanisms; you'd probably be going through that in libmill-based sources. The clash, if it happens, has very easy, localized workarounds. Note that the library has a macro called end, which is a very common identifier in programs. Why didn't the author consider that a problem, but switched Go's select to choose?

legohead 7y ago
select is super well known in C, as I'm sure you're aware. I have over 20 years in it myself. sure, workarounds are easy, but that's not the point. your suggestion that it should be named the same as Go is a bit ridiculous. why is that even important? what is important is potentially confusing developers, and adding a new "select" into C would do just that. the only mistake is Go using the word select to begin with.
- kazinator 7y ago
  select isn't in C; it's in POSIX. I worked in Windows development shops where nobody knew select; but they could write WaitForMultipleObjects code in their sleep. A strictly conforming ISO C program can use the select identifier however it wants, including as an external name for an object or function. > your suggestion that it should be named the same as Go is a bit ridiculous It's not any more ridiculous than wanting to have a library which imitates Go concurrency down to macros that imitate some of the syntax.
  - xeeeeeeeeeeenu 7y ago
    >I worked in Windows development shops where nobody knew select; but they could write WaitForMultipleObjects code in their sleep. That's hard to believe considering the fact that POSIX-compatible select() is a part of the winsock API.
- geezerjay 7y ago
  > your suggestion that it should be named the same as Go is a bit ridiculous. Are you aware that you're making that complaint in a discussion on Libmill: Go-Style Concurrency in C? It's one thing to skip the submission to jump to the comment section. It's an entirely different thing to start mindlessly criticizing constructive criticism presented by fellow users while being entirely oblivious to both the subject and the context. That's just noise, and contributes zero to the discussion. In fact, it takes an awful lot from it.
  - fao_ 7y ago
    > Are you aware that you're making that complaint in a discussion on Libmill: Go-Style Concurrency in C? Just because it's Go-style, doesn't mean "Exactly like Go, down to the keywords used".
    - geezerjay 7y ago
      > Just because it's Go-style, doesn't mean "Exactly like Go, down to the keywords used". That point was already discussed previously in the discussion, and it's pointless to continue repeating what has already been said, particularly when those arguments boil down to nothing more than a personal opinion.
      - fao_ 7y ago
        I read the entire discussion and didn't see a single person mention it, but ok.

newnewpdro 7y ago

While I agree it's poor form to reuse the word 'select' for obvious reasons, there are few circumstances where it makes sense to use the select() interface in any new programs. It's a very common source of hidden bugs thanks to FD_SETSIZE.

kazinator 7y ago
It also performs badly due to to all the bitmask twiddling, and copying of those bitmasks to the kernel and back. If you want to select on file descriptor 1000, the bitmask has to include zeros for descriptors 0 through 999. Those get copied to the kernel and iterated over dutifully.