Announcement

Collapse
No announcement yet.

Linux Changes Pipe Behavior After Breaking Problematic Android Apps On Recent Kernels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by F.Ultra View Post
    Level-trigger will return from epoll_wait as long as there is data to read, aka as long as the kernel buffer has data the level is set so the difference would be that in the case where you don't empty the buffer until EAGAIN edge would not provide further events while level would return immediately.
    In the intermediate version, and in that scenario, reading until EAGAIN is required to avoid infinite blocking. And it seems that if doing that, then edge-triggered and level-triggered will behave the same. (Except for a multi-threaded scenario like I described above, which however would work *only* with the intermediate version.)

    Originally posted by F.Ultra View Post
    I guess it's multiple processes and written to be run on systems without named semaphores?
    I'd think for example System V semaphores would be an alternative. I don't know if maybe some relevant system would not have inter-process semaphores at all, though I wouldn't expect that. But maybe pipes are considered better portable, and the intention was to avoid system-specific code for different semaphore APIs.

    Originally posted by F.Ultra View Post
    Now it sounds like you control both the read and the writer here, but would such a setup not make your application to end up in a situation where the processing never happens due to some of the write events being merged into a single one so you hang on epoll_wait?
    Actually no, since without a receipt, there will be no additional update message (that could be merged). This is to avoid a flood of update messages at times when they can't be processed. I could imagine a similar mechanism to guarantee the ability to re-send a message even in situations when the connection needs to be re-established.

    Comment


    • #52
      Originally posted by indepe View Post
      Actually no, since without a receipt, there will be no additional update message (that could be merged). This is to avoid a flood of update messages at times when they can't be processed. I could imagine a similar mechanism to guarantee the ability to re-send a message even in situations when the connection needs to be re-established.
      But what happens if due to timing issues (your reading thread gets scheduled between epoll_wait and read due to paging/whatever) so the last receipt+updates gets merged into a single message, then you only read part of the buffer and only discover the receipt but not the updates?! Unless of course you do some checking on timeout.

      Comment


      • #53
        Originally posted by F.Ultra View Post
        But what happens if due to timing issues (your reading thread gets scheduled between epoll_wait and read due to paging/whatever) so the last receipt+updates gets merged into a single message, then you only read part of the buffer and only discover the receipt but not the updates?! Unless of course you do some checking on timeout.
        It sounds like you misunderstood me. The receipt goes in the opposite direction, back to the sender of the update message. Or maybe I don't understand your point.

        Comment


        • #54
          Originally posted by indepe View Post

          It sounds like you misunderstood me. The receipt goes in the opposite direction, back to the sender of the update message. Or maybe I don't understand your point.
          ah, that makes more sense, thought you talked about messages in one direction only here

          Comment

          Working...
          X