Who should set the priority of a select(2)ing thread being waken up?

From: Seigo Tanimura (tanimura_at_tanimura.dyndns.org)
Date: 10/22/03

  • Next message: Seigo Tanimura: "Re: Who should set the priority of a select(2)ing thread being waken up?"
    Date: Wed, 22 Oct 2003 12:19:16 +0900
    To: arch@FreeBSD.org
    
    

    In good old days, only a socket and a pipe were the major file
    descriptors being select(2)ed. As select(2) was just a socket
    operation, it was sufficient to set the priority of select(2)ing
    process to PSOCK(*1), I suppose.

    Nowadays, quite a few drivers support select(2) as well, including
    sound, usb, scsi controllers, and so on. I am not convinced whether a
    process should select(2) those devices at PSOCK as we do for a socket.

    Suppose that a process select(2)s for a pcm device and a socket at
    once. If the process is waken up by the pcm driver at PSOCK, another
    process at a better priority may preempt the first one, which can
    result in dropping some pcm data.

    Maybe it would be better if the caller of selwakeup() could determine
    the priority of a process or a thread. That would let us raise the
    priority to PRIBIO if pcm data was ready, while the priority would
    stay at PSOCK if the socket was ready.

    (*1) I broke that in 5-CURRENT when I modified select(2) and poll(2)
    to use a conditional variable.

    -- 
    Seigo Tanimura <tanimura@tanimura.dyndns.org> <tanimura@FreeBSD.org>
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Seigo Tanimura: "Re: Who should set the priority of a select(2)ing thread being waken up?"

    Relevant Pages

    • Re: Socket priority
      ... I'm talking about pulling the code to do the hardware I/O *out* of the ... not a DLL. ... ...and it's a "blocking" socket. ... increase priority to the socket and decrease priority to the JIT. ...
      (microsoft.public.windowsce.embedded.vc)
    • Re: runaway thread count and asynchronous sockets
      ... explicitly spawn in my server a normal priority. ... threads spawned by the CLR to handle the async socket communication. ... >> thread you spin off so high thread counts in and of themselves are not always ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Socket priority
      ... I'm talking about pulling the code to do the hardware I/O *out* of the ... not a DLL. ... You can't control the priority of the JITter and I don't think that you're ... ...and it's a "blocking" socket. ...
      (microsoft.public.windowsce.embedded.vc)
    • Re: Socket priority
      ... I'm talking about pulling the code to do the hardware I/O *out* of the ... not a DLL. ... You can't control the priority of the JITter and I don't think that you're ... ...and it's a "blocking" socket. ...
      (microsoft.public.windowsce.embedded.vc)
    • Re: Socket priority
      ... various socket calls that can affect how things work (is the socket async or ... Inside eVC++ DLL I use the follow: ... but what's the "socket process" priority? ... The thread have an higher priority than the VB application. ...
      (microsoft.public.windowsce.embedded.vc)