See BeginWriteCore ... it already allocates the OVERLAPPED.
From: Peter Ritchie <[EMAIL PROTECTED]> Reply-To: "Discussion of advanced .NET topics." <[email protected]> To: [email protected] Subject: Re: [ADVANCED-DOTNET] Possible defect in BeginWrite on FileStream Date: Mon, 19 Dec 2005 11:20:49 -0500 If you want it to be thread-safe (which seems to be the intention of wanting an atomic BeginWrite that accepts offset and data to be any different than calling Seek/BeginWrite), it's quite a bit more complicated. Each call to BeginWrite would have to allocate a new OVERALAPPED structure to atomically track that individual write, and somehow store it in the IAsyncResult object it returns. You'd probably also want the event handle for each of those writes to be monitored on individual threads so when it calls the application's callback it doesn't block the completion of any other writes. Again, because we want to add more than Seek/BeginWrite already offers. Nothing ground-breaking to implementing this; but, not the "pretty easy" you seem to think. BTW, FileStream.BeginWrite is already asynchronous; "AsyncFileStream" doesn't make sense. http://www.peterRitchie.com/ On Mon, 19 Dec 2005 09:09:52 -0600, John Davis <[EMAIL PROTECTED]> wrote: >Fair enough, we need an AsyncFileStream class which inherits from FileStream >and has BeginWrite/Read methods on it which contain file offset arguments. >This should be pretty easy since all the async code in there is already >running off of OVERLAPPED structs. > > >>From: Ian Griffiths <[EMAIL PROTECTED]> >>Reply-To: "Discussion of advanced .NET topics." >><[email protected]> >>To: [email protected] >>Subject: Re: [ADVANCED-DOTNET] Possible defect in BeginWrite on FileStream >>Date: Sat, 17 Dec 2005 14:00:57 -0000 >> >>It seems to me that there's a clear difference between what Seek gives >>you and what you're asking for. (Otherwise you wouldn't be asking for >>it.) I admit that I chose poor terminology to describe the feature: I >>should have said "concurrent random access" rather than just "random >>access". But I stand by my assertion that it shouldn't be in Stream. >> >>The problem I have with adding this to the Stream abstraction is that >>all of a sudden, *every* Stream has to support it. >> >>So you undoubtedly *could* have something not dissimilar to Stream that >>support concurrent random access. But if you made this a feature of >>Stream you just made it mandatory for every implementation of Stream to >>support this. >> >>That makes it a non-starter for where we are today - this suggestion >>will never fly because Stream shipped almost 4 years ago, and there's no >>way to go and add this functionality retrospectively to all the Streams >>everyone has implemented ever since. >> >>Given where we are, the only way to add this functionality would be to >>introduce a new more specialized abstraction. (Either specifically to >>files, or possibly as some new AsyncStream abstraction.) >> >>So this leaves this discussion as an academic question: should Stream >>have had this functionality from the start? >> >>I think Stream's better without this, because this extra feature would >>increase the cost of implementing Stream. And this is the tradeoff you >>often get with abstractions: making them rich enough to be useful but >>simple enough that anyone can be bothered to implement them. >> >>Mandating that all streams that support seeking also support concurrent >>random access seems like a high tax to impose on implementing Stream. >> >>If everyone were clamouring for it, then it'd be reasonable. But >>they're not. I've worked on a wide range of .NET projects in the years >>since .NET shipped, and while I can appreciate in abstract that this >>would be a nice feature, I've never run into a scenario where this would >>have been useful in practice. (But I have run into scenarios where I >>wanted to implement Stream. So this feature would have been a net loss >>for me.) >> >>More tellingly, you rarely see anyone asking for it on public forums. As >>far as I can tell from the various mailing lists, newsgroups, and forums >>I've hung out on, my experience of never having come across a concrete >>need for this is more common than your experience. >> >>Which suggests that Microsoft made the right decision: Stream would have >>been the wrong place to put support for concurrent random access. >> >>So even if you were starting from a clean slate, and wanted v1.0 of the >>framework to offer this functionality (and I agree it would be nice to >>have, despite the fact that I've never actually needed it) I still think >>it would be a mistake to put something this specialized into something >>as generic as Stream. >> >>It's at best a poor match (and at worst, inappropriate) for most >>implementations of Stream. For the implementations of Stream for which >>it's appropriate, it's not useful most of the time. >> >>To steal a phrase that Ron Jeffries recently used on the TDD mailing >>list: >> >> " it would be a bit like having a #10 Torx driver as part >> of my hammer. Occasionally useful but also an odd addition." >> >> >>Of course it's hugely frustrating if you happen to hit the case where >>you want to do something that you know would be pretty easy for the >>underlying implementation you happen to be using. But that doesn't >>translate into an argument that Stream is designed wrong. >> =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
