[racket-users] How to check a place-channel for a message without blocking?

2015-09-01 Thread Charles Hixson
Is there a way to check whether there is a message available to be 
picked up on a place-channel without blocking?


(If there isn't, the only way forwards for me in Racket is via a server. 
possibly a tcp server, though I don't really want the handshake.  
Possibly a Unix Socket Server.  Possibly a zmq library.)


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread charleshixsn
Is there a way to check whether there is a message available to be picked up on 
a place-channel without blocking?

(If there isn't, the only way forwards for me in Racket is via a server. 
possibly a tcp server, though I don't really want the handshake.  Possibly a 
Unix Socket Server.  Possibly a zmq library.)

P.S.:  Appologies if this turns out to be a duplicate, but the first post 
didn't show up for a couple of hours.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread Robby Findler
The usual way to do this is by building your own syncronization
pattern using an extra thread. There are situations where that isn't
efficient enough, but it often works great. Threads in racket aren't
heavy weight and using this "CML style" of programming is very
flexible and naturally leads to very general purpose communication
patterns that are coded up via little recursive functions. Give it a
try!

Robby

On Mon, Aug 31, 2015 at 6:19 PM,   wrote:
> Is there a way to check whether there is a message available to be picked up 
> on a place-channel without blocking?
>
> (If there isn't, the only way forwards for me in Racket is via a server. 
> possibly a tcp server, though I don't really want the handshake.  Possibly a 
> Unix Socket Server.  Possibly a zmq library.)
>
> P.S.:  Appologies if this turns out to be a duplicate, but the first post 
> didn't show up for a couple of hours.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread charleshixsn
On Monday, August 31, 2015 at 4:21:37 PM UTC-7, Robby Findler wrote:
> The usual way to do this is by building your own syncronization
> pattern using an extra thread. There are situations where that isn't
> efficient enough, but it often works great. Threads in racket aren't
> heavy weight and using this "CML style" of programming is very
> flexible and naturally leads to very general purpose communication
> patterns that are coded up via little recursive functions. Give it a
> try!
> 
> Robby
> 
OK, I'm not familiar with "Concurrent ML" which is what I'm guessing CML style 
refers to, so let me check my understanding.

The place channel is accessed via a secondary thread, that receives the 
messages via place-channel-get, blocking until it receives something.  When it 
does it posts it to mailbox of the main thread (the one that does the work).  
When it has time it does a (thread-try-recieve) to get the next piece of data 
to work on.

Yeah, that sounds like it would work.  Thanks.  That had me rather stumped.  If 
that's what you meant (or even if it sounds to you like a good way to proceed) 
I guess I should buckle down and learn Racket.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread Robby Findler
Yes, right!

I agree that for a simple thing like just checking availability of a
message it feels like a lot. But when you get more complex
syncronization patterns it scales up very nicely.

Robby


On Mon, Aug 31, 2015 at 6:54 PM,   wrote:
> On Monday, August 31, 2015 at 4:21:37 PM UTC-7, Robby Findler wrote:
>> The usual way to do this is by building your own syncronization
>> pattern using an extra thread. There are situations where that isn't
>> efficient enough, but it often works great. Threads in racket aren't
>> heavy weight and using this "CML style" of programming is very
>> flexible and naturally leads to very general purpose communication
>> patterns that are coded up via little recursive functions. Give it a
>> try!
>>
>> Robby
>>
> OK, I'm not familiar with "Concurrent ML" which is what I'm guessing CML 
> style refers to, so let me check my understanding.
>
> The place channel is accessed via a secondary thread, that receives the 
> messages via place-channel-get, blocking until it receives something.  When 
> it does it posts it to mailbox of the main thread (the one that does the 
> work).  When it has time it does a (thread-try-recieve) to get the next piece 
> of data to work on.
>
> Yeah, that sounds like it would work.  Thanks.  That had me rather stumped.  
> If that's what you meant (or even if it sounds to you like a good way to 
> proceed) I guess I should buckle down and learn Racket.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread charleshixsn
On Monday, August 31, 2015 at 4:58:01 PM UTC-7, Robby Findler wrote:
> Yes, right!
> 
> I agree that for a simple thing like just checking availability of a
> message it feels like a lot. But when you get more complex
> syncronization patterns it scales up very nicely.
> 
> Robby
> 
> 
> On Mon, Aug 31, 2015 at 6:54 PM,   wrote:
> > On Monday, August 31, 2015 at 4:21:37 PM UTC-7, Robby Findler wrote:
> >> The usual way to do this is by building your own syncronization
> >> pattern using an extra thread. There are situations where that isn't
> >> efficient enough, but it often works great. Threads in racket aren't
> >> heavy weight and using this "CML style" of programming is very
> >> flexible and naturally leads to very general purpose communication
> >> patterns that are coded up via little recursive functions. Give it a
> >> try!
> >>
> >> Robby
> >>
> > OK, I'm not familiar with "Concurrent ML" which is what I'm guessing CML 
> > style refers to, so let me check my understanding.
> >
> > The place channel is accessed via a secondary thread, that receives the 
> > messages via place-channel-get, blocking until it receives something.  When 
> > it does it posts it to mailbox of the main thread (the one that does the 
> > work).  When it has time it does a (thread-try-recieve) to get the next 
> > piece of data to work on.
> >
> > Yeah, that sounds like it would work.  Thanks.  That had me rather stumped. 
> >  If that's what you meant (or even if it sounds to you like a good way to 
> > proceed) I guess I should buckle down and learn Racket.
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

Many thanks.  

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] How to check a place-channel for a message without blocking?

2015-08-31 Thread Robby Findler
Oh, and I should point out that I forgot about sync/timeout. If you
pass 0 as the timeout, you can get the behavior you were asking for.

Sorry about that.

Robby

On Mon, Aug 31, 2015 at 7:51 PM,   wrote:
> On Monday, August 31, 2015 at 4:58:01 PM UTC-7, Robby Findler wrote:
>> Yes, right!
>>
>> I agree that for a simple thing like just checking availability of a
>> message it feels like a lot. But when you get more complex
>> syncronization patterns it scales up very nicely.
>>
>> Robby
>>
>>
>> On Mon, Aug 31, 2015 at 6:54 PM,   wrote:
>> > On Monday, August 31, 2015 at 4:21:37 PM UTC-7, Robby Findler wrote:
>> >> The usual way to do this is by building your own syncronization
>> >> pattern using an extra thread. There are situations where that isn't
>> >> efficient enough, but it often works great. Threads in racket aren't
>> >> heavy weight and using this "CML style" of programming is very
>> >> flexible and naturally leads to very general purpose communication
>> >> patterns that are coded up via little recursive functions. Give it a
>> >> try!
>> >>
>> >> Robby
>> >>
>> > OK, I'm not familiar with "Concurrent ML" which is what I'm guessing CML 
>> > style refers to, so let me check my understanding.
>> >
>> > The place channel is accessed via a secondary thread, that receives the 
>> > messages via place-channel-get, blocking until it receives something.  
>> > When it does it posts it to mailbox of the main thread (the one that does 
>> > the work).  When it has time it does a (thread-try-recieve) to get the 
>> > next piece of data to work on.
>> >
>> > Yeah, that sounds like it would work.  Thanks.  That had me rather 
>> > stumped.  If that's what you meant (or even if it sounds to you like a 
>> > good way to proceed) I guess I should buckle down and learn Racket.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to racket-users+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> Many thanks.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.