In article <ca3jd3$2p74$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ca3hvs$2mse$1@digitaldaemon.com>, Sean Kelly says...
>
>>Just user BufferedStream like Ben says.  I don't think it's mentioned in the docs, but the class does exist.
>
>Thanks for the info that D has BufferedStream. I didn't know that, and it really should be in the docs.
>
>But as to the advice that I use it, I believe you have completely misunderstood my needs. I guess that doesn't matter though - thanks for trying to help anyway.

BufferedStream doesn't have a method to return how many bytes are available in the buffer, which is what I think you were asking for, but it wouldn't be too hard to add (even as a temporary hack for your own uses).  I just started looking at streams yesterday to see what they might be missing, so assuming my submissions are accepted perhaps the wait won't be too long.  In this case, perhaps soemthing along the lines of std::istream::readsome added to BufferedStream would suit.


Sean

Jill,

What you're asking for is kinda' tricky to place in a class such as stream (even though the Java lib has it). I think this boils down to a classic producer/consumer issue, where the consumer wants to know if there's anything ready for, uhhh, consumption ... traditional approaches place the producer on a separate thread and use a synch-point, rendezvous, or exchange mechanism to synchronize the pair; with a time-out period provided by the consumer. That is, the consumer says "I'll wait X microseconds for something to become available; then I'm outta here". This may have been what Ben Hinkle was suggesting.

Perhaps Ben and/or Mike could advise you on the finer points within the Concurrent library, but that's the place to go; Doug Lea seems to have spent a lifetime perfecting the library that those two guys are converting. At this point the Concurrent project does not have Rendezvous, but does have Exchanger. The latter could be used to build a nice wee wrapper around a producer thread that suits your purposes ...

- Kris


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca3jo6$2pl3$1@digitaldaemon.com...
> In article <ca3ia2$2nf5$1@digitaldaemon.com>, Brad Anderson says...
> >
> >Might I suggest Mango.io instead of Phobos modules?  I've been pretty happy with this part of the Mango tree, even though there's a nice http client, server, and servlet container there as well.
>
> Everyone on this newsgroup is really nice, and I really do appreciate all
these
> offers of help from people. (And I will look at mango as well). But, alas,
you
> have also completely misunderstood my needs.
>
> I want a function equivalent to Java's java.io.InputSream.available()
added to
> D's std.stream.Stream() and its subclasses. [Or alternatively, a
willBlock()
> function]. Nothing less will suffice.
>
> If it can't be done, then it can't be done. End of story. Then I just move
on to
> something else.
>
> Arcane Jill
>
>

In article <ca4p2n$1smd$1@digitaldaemon.com>, Kris says...
>
>Jill,
>
>What you're asking for is kinda' tricky to place in a class such as stream (even though the Java lib has it). I think this boils down to a classic producer/consumer issue, where the consumer wants to know if there's anything ready for, uhhh, consumption ... traditional approaches place the producer on a separate thread and use a synch-point, rendezvous, or exchange mechanism to synchronize the pair; with a time-out period provided by the consumer. That is, the consumer says "I'll wait X microseconds for something to become available; then I'm outta here". This may have been what Ben Hinkle was suggesting.
>
>Perhaps Ben and/or Mike could advise you on the finer points within the Concurrent library, but that's the place to go; Doug Lea seems to have spent a lifetime perfecting the library that those two guys are converting. At this point the Concurrent project does not have Rendezvous, but does have Exchanger. The latter could be used to build a nice wee wrapper around a producer thread that suits your purposes ...

I think what Jill needs at the moment is far more simple.  A buffer always knows how many bytes it has stored.  But for some things the producer/consumer model is certainly the way to go.  I've got a multiplexed socket library I'm considering porting to D, though I may decide on a redesign based on the unfinished Boost api.  Either way, that's on my to do list.  Though it may need to wait until Ben finishes with the Concurrent lib port.

Sean

> Perhaps Ben and/or Mike could advise you on the finer points within the Concurrent library, but that's the place to go; Doug Lea seems to have
spent
> a lifetime perfecting the library that those two guys are converting. At this point the Concurrent project does not have Rendezvous, but does have Exchanger. The latter could be used to build a nice wee wrapper around a producer thread that suits your purposes ...

It's a little embarrassing but I've switched code-bases for that library. Mike and I were porting Doug's original library, which contained Rendezvous, andeverything was fine. When I emailed Doug he strongly suggested using the newer JSR166 code which had Exchanger but no Rendezvous. When I initially looked at the two libraries I thought they were essentially the same and so I went with the stand-alone version but once Doug suggested going with the newer code I took another look and realized the styles are actually pretty different. For instance the old code was entirely based on the built-in synchronized/wait/notify but the new stuff implements the synchronization totally independently (and depending on an undocumented Sun package called sun.misc.unsafe).

So to make a long story short I ripped out the Rendezvous and put in Exchanger. Same goes for the other basic stuff. Doug indicated somewhere the "more esoteric" classes like Rendezvous might get released in an optional package sometime and when that happens we can port it. But for the time being it's gonna be JSR166. The channel and fork/join code will probably keep using the old code but we're looking into it.

-Ben