1. 14 Feb, 2019 2 commits
  2. 08 Feb, 2019 1 commit
  3. 07 Feb, 2019 1 commit
  4. 06 Feb, 2019 3 commits
  5. 05 Feb, 2019 10 commits
  6. 12 Jan, 2019 1 commit
    • step-'s avatar
      Fix two race conditions (notebook and paned) · f85496bd
      step- authored
      Before this commit there were two Critical Regions (CR) that could lead
      to race conditions:
      * among yad --plug processes, and   
      * between yad --key (notebook or paned) and yad --plug processes.
      
      The first CR had been marked as suspected in the existing code with
      this comment `/* FIXME: may be race here */` but no fix. This CR
      could lead to a race condition between multiple plugs trying to
      increment counter `tabs[0].xid++` all at once. Given a collision, the
      xid counter would never reach its target value, which is the number of
      plugs connected to notebook (or paned). Therefore the notebook
      or paned dialog would wait forever and never display their windows.
      One could run `ps` and watch several yad processes sleeping in the
      process list without visible yad windows.
      
      To fix this problem I redefined the role of `tabs[0].xid` from a
      read/write counter to a read-only (from the perspective of plugs)
      boolean flag. Only when the flag goes true are the plugs allowed to
      write to shared memory -- each plug to its own memory space `tabs[i]`.
      This eliminates the CR therefore the problem. With this change only
      the yad --key process is allowed to write `tabs[0]`.
      
      The second CR occurred inside function `get_tabs` when the yad --key
      process attached shared memory and initialized the `tabs[i]` slots.
      In a race condition this initialization could overwrite a plug's slot
      _after_ the plug had written the slot. This would make GTK unable to
      set up a socket between the plug and the key therefore the key would
      hang forever without displaying its window.
      
      To fix this problem I used again `tabs[0].xid` as explained above to
      make sure that `tabs[0].xid=1` (TRUE) is set only after the key has
      initialized the shared memory block. While the flag is false, plug
      can attach shared memory but they aren't allowed to write their slots.
      After the flag is set true (and never reset false), each plug can write
      only its own slot `tabs[i]`, for which there is no contention.
      
      There was no need to set up a mutex or semaphore to solve the race
      conditions.
      f85496bd
  7. 28 Oct, 2018 1 commit
    • step-'s avatar
      Fix --list prints empty cell as "(null)" · 6172f375
      step- authored
      To illustrate the issue before and after this fix:
      
          # /usr/bin/yad --list --print-all --column=A a '' c
          a|
          (null)|
          c|
          # ./src/yad --list --print-all --column=A a '' c
          a|
          |
          c|
      
      The empty string '' in the second row results in a NULL C pointer,
      which g_printf prints as "(null)". The fix consists of passing the
      empty string "" to g_printf when the pointer is NULL.
      6172f375
  8. 10 Oct, 2018 1 commit
  9. 21 Sep, 2018 1 commit
  10. 21 Aug, 2018 1 commit
  11. 30 Jul, 2018 1 commit
  12. 22 Jul, 2018 1 commit
  13. 08 Jun, 2018 1 commit
  14. 07 Jun, 2018 1 commit
  15. 19 May, 2018 2 commits
  16. 16 May, 2018 1 commit
  17. 03 May, 2018 2 commits
  18. 02 May, 2018 3 commits
  19. 29 Apr, 2018 6 commits