From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d6f01a357b7f98ce,start X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!v53g2000hsa.googlegroups.com!not-for-mail From: mhamel_98@yahoo.com Newsgroups: comp.lang.ada Subject: Direct_Io for Filesystem question Date: Thu, 23 Oct 2008 12:52:20 -0700 (PDT) Organization: http://groups.google.com Message-ID: <817032b7-4e8a-4589-9e44-00e7aef1fb06@v53g2000hsa.googlegroups.com> NNTP-Posting-Host: 132.228.195.207 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1224791541 12814 127.0.0.1 (23 Oct 2008 19:52:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 23 Oct 2008 19:52:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v53g2000hsa.googlegroups.com; posting-host=132.228.195.207; posting-account=5z8IJQkAAAAuH1CVqapXiEqPOXq8UfDM User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:2472 Date: 2008-10-23T12:52:20-07:00 List-Id: Hello all, I have a "filesystem" that I've been using for some time now and with some free time on my hand I thought I would play around with concurrency. I use the term filesystem very loosely, its simply an instantiation of Direct_Io with a variant record, the first record in a file is a header and the rest is data and it has worked well enough. My approach to concurrency was instead of giving the direct_io.file_type to a requesting process, I would create my own file_type which really only contains a token and location value. The token would direct the filesystem package to the actual file and the location value which record to read/write. When an 'open' is called, it checks to see if the file is already open and if so returns an existing token, and if not, opens it and creates a token to perhaps be shared with others later. All reads and writes are done using the Direct_Io calls requiring a record index. What the internal index of the file_type is I don't care (maybe I should?) This also works well in a single user case. In the case of two readers, the second reader reads a little bit then tosses an End_Error exception, the first reader completes normally. Again, I'm wondering if the internal index value is relevant. I would have thought that explicitly telling direct_io which record to read it would not care where it last read. In the case of simultaneous reading and writing (only one writer allowed), I designed the code so that when a reader opens the file, it is told that the end of the file is where the writer is currently located, so the reader will stop before overruning the writing process' location, and this implementation is fine, no real time requirements (that might be a neat addition later). When I run a test of one reader and one writer, on the surface everything seems ok, no errors thrown. When I go over the data later I get "discriminant check failed" for a few records. Its as if the few moments a reader is active, the writer tosses in garbage for the records written during that time span. I guess the big question is, am I ok to use Direct_Io for this sort of operation? It seems to me that the case of multiple readers is really not much more than one reader doing very random reads? If anyone has specific information on the symptoms I'm seeing, I'd really appreciate it! Thanks for any advice or opinions!