Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you set the sigevent argument in the lio_listio() call, you will be notified with a signal (or function call) when all the jobs in that one particular call completes. You would still need to:</p> <ol> <li><p>wait until you receive as many notifications as you have made lio_listio() calls, to know when they're all done.</p></li> <li><p>use some safe mechanism to communicate from your signal handler to your main thread, probably via a global variable (to be portable).</p></li> </ol> <p>If you're on linux, I would recommend tying an eventfd to your sigevent instead and wait on that. That's a lot more flexible since you don't need to involve signal handlers. On BSD (but not Mac OS), you can wait on aiocbs using kqueue and on solaris/illumos you can use a port to get notified of aiocb completions.</p> <p><a href="http://www.xmailserver.org/eventfd-aio-test.c" rel="nofollow">Here's an example</a> of how to use eventfds on linux:</p> <p>As a side note, I would use caution when issuing jobs with lio_listio. You're not guaranteed that it supports taking more than <a href="http://pubs.opengroup.org/onlinepubs/009696699/basedefs/limits.h.html" rel="nofollow">2 jobs</a>, and some systems have very low limits of how many you can issue at a time. Default on Mac OS for instance is 16. This limit may be defined as the AIO_LISTIO_MAX macro, but it isn't necessarily. In which case you need to call sysconf(_SC_AIO_LISTIO_MAX) (see <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html" rel="nofollow">docs</a>). For details, see the <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/lio_listio.html" rel="nofollow">lio_listio documentation</a>.</p> <p>You should at least check error conditions from your lio_listio() call.</p> <p>Also, your solution of using a mutex is sub-optimal, since you will synchronize each loop in the for loop, and just run one at a time (unless it's a recursive mutex, but in that case its state could be corrupt if your signal handler happens to land on a different thread).</p> <p>A more appropriate primitive may be a semaphore, which is released in the handler, and then (after your for loop) acquired the same number of times as you looped, calling lio_listio(). But, I would still recommend an eventfd if it's OK to be linux specific.</p>
    singulars
    1. This table or related slice is empty.
    1. POlio_listio: How to wait until all requests complete?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USArvid
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POlio_listio: How to wait until all requests complete?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for a very informative post. Synchronizing each loop is what I want, since I'm using something akin to a double buffer to store the computed data - if there's no other problem with the mutex solution, it should be OK for my purpose. I wasn't aware of these limitations of lio_listio() - I will investigate whether using an `mmap`ed file would be better.
      singulars
      1. PO
      1. USKrzysztof Kosiński
    2. COyeah, in that case I would imagine your solution with a mutex work fine. The only thing that I would worry about a bit is the pattern of releasing the mutex inside a signal handler, potentially on the thread that's currently blocked in acquiring the lock (for a list of signal-handler-safe system calls: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03). you're using the mutex in a pattern where traditionally semaphores are used.
      singulars
      1. PO
      1. USArvid
    3. COIndeed, it looks like the pthread_mutex_* functions are not async-signal-safe, while sem_post is.
      singulars
      1. PO
      1. USKrzysztof Kosiński
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload