Browse thread
How to read different ints from a Bigarray?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Gerd Stolpmann <gerd@g...> |
| Subject: | Re: [Caml-list] Re: How to read different ints from a Bigarray? |
Am Freitag, den 30.10.2009, 00:43 +0100 schrieb Goswin von Brederlow: > Gerd Stolpmann <gerd@gerd-stolpmann.de> writes: > > > Am Donnerstag, den 29.10.2009, 21:40 +0100 schrieb Florian Weimer: > >> * Goswin von Brederlow: > >> > >> > - The data is passed to libaio and needs to be kept alive and unmoved > >> > as long as libaio knows it. > >> > >> It also has to be aligned to a 512-byte boundary, so you can use > >> O_DIRECT. Linux does not support truely asynchronous I/O without > >> O_DIRECT AFAIK, which rarely makes it worth the trouble. > > > > Right. There is also the question whether aio for regular files (i.e. > > files backed by page cache) is continued to be supported at all - it is > > well known that Linus Torvalds doesn't like it. It can happen that at > > some day aio will be restricted to block devices only. > > > > So I wouldn't use it for production code, but it is of course still an > > interesting interface. > > > > Gerd > > Damn. That seems so stupid. Then writing asynchronous will only be > possible with creating a pot full of worker thread, each one writing > one chunk. So you get all those chunks in random order submitted to > the kernel, the kernel has to reorder them, fit them back together, > write them and then wake up the right thread for each piece > completed. So much extra work while libaio has all the data already in > perfect structures for the kernel. Well, this is exactly the implementation of the POSIX aio functions in glibc. They are mapped to a bunch of threads. > And how will you do barriers when writing with threads? Wait for all > threads to complete every time you hit a barrier and thereby stalling > the pipeline? You can't implement barriers. When you have page-cache backed I/O (i.e. non-direct I/O, no matter of aio or sync I/O) there is no control when data is written. Ok, there is fsync but this is very coarse-grained control. Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------