Smalltalk › Squeak › Squeak - Beginners

Read a filestream (named pipe) with a timeout

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 9 messages Options
dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Read a filestream (named pipe) with a timeout

dsl101
I'm using Squeak 4.2 and working on the smalltalk end of a named pipe connection, which sends a message to the named pipe server with:

        msg := 'Here''s Johnny!!!!'.
        pipe nextPutAll: msg; flush.

It should then receive an acknowledgement, which will be a 32-byte md5 hash of the received message (which the smalltalk app can then verify). It's possible the named pipe server may have gone away or otherwise been unable to deal with the request, and so I'd like to set a timeout on reading the acknowledgement. I've tried using this:

        ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3) onTimeout: [ 'timeout'. ].

and then made the pipe server pause artificially to test the code. But the smalltalk thread blocks on the read and doesn't carry on (even after the timeout), although if I then get the pipe server to send the correct response (after a 5 second delay, for example), the value of 'ack' is 'timeout'. Obviously the timeout did what it's supposed to do, but couldn't 'unblock' the blocking read on the pipe.

Is there a way to accomplish this even with a blocking FileStream read? I'd rather avoid a busy wait on there being 32 characters available if at all possible.

Thanks,

Dave
Ron Teitelbaum
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: Read a filestream (named pipe) with a timeout

Ron Teitelbaum
Hi Dave,

See #dataAvailable  and #recieveAvailableData.

It's never good to call for data if you don't know you have any.  Better to
setup a wait for data until call instead.  

All the best,

Ron Teitelbaum
Head Of Engineering
3d Immersive Collaboration Consulting
[hidden email]
Follow Me On Twitter: @RonTeitelbaum
www.3dicc.com
https://www.google.com/+3dicc


> -----Original Message-----
> From: [hidden email] [mailto:beginners-
> [hidden email]] On Behalf Of dsl101
> Sent: Thursday, January 09, 2014 10:16 AM
> To: [hidden email]
> Subject: [Newbies] Read a filestream (named pipe) with a timeout
>
> I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
> connection, which sends a message to the named pipe server with:
>
> msg := 'Here''s Johnny!!!!'.
> pipe nextPutAll: msg; flush.
>
> It should then receive an acknowledgement, which will be a 32-byte md5
hash of
> the received message (which the smalltalk app can then verify). It's
possible the
> named pipe server may have gone away or otherwise been unable to deal with
> the request, and so I'd like to set a timeout on reading the
acknowledgement.
> I've tried using this:
>
> ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
onTimeout: [
> 'timeout'. ].
>
> and then made the pipe server pause artificially to test the code. But the
> smalltalk thread blocks on the read and doesn't carry on (even after the
> timeout), although if I then get the pipe server to send the correct
response
> (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
Obviously
> the timeout did what it's supposed to do, but couldn't 'unblock' the
blocking
> read on the pipe.
>
> Is there a way to accomplish this even with a blocking FileStream read?
I'd rather
> avoid a busy wait on there being 32 characters available if at all
possible.
>
> Thanks,
>
> Dave
>
>
>
> --
> View this message in context:
http://forum.world.st/Read-a-filestream-named-
> pipe-with-a-timeout-tp4735456.html
> Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

dsl101
Hi Ron,

Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there), but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

start := DateAndTime millisecondClockValue.
(pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
(Delay forMilliseconds 50) wait.
]
pipe size = 32 ifTrue: [
"Get data"
] ifFalse: [
"Deal with timeout"
]

The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back. That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.

I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing I'll have to do something like this:
  • Set up a semaphore
  • Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
  • In the main thread, wait for up to 3 seconds for the semaphore to be signalled
  • If the semaphore times out, kill the forked process
Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?

Thanks,

Dave


On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
Hi Dave,

See #dataAvailable  and #recieveAvailableData.

It's never good to call for data if you don't know you have any.  Better to
setup a wait for data until call instead.  

All the best,

Ron Teitelbaum
Head Of Engineering
3d Immersive Collaboration Consulting
[hidden email]
Follow Me On Twitter: @RonTeitelbaum
www.3dicc.com
https://www.google.com/+3dicc


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of dsl101
> Sent: Thursday, January 09, 2014 10:16 AM
> To: [hidden email]
> Subject: [Newbies] Read a filestream (named pipe) with a timeout
>
> I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
> connection, which sends a message to the named pipe server with:
>
> msg := 'Here''s Johnny!!!!'.
> pipe nextPutAll: msg; flush.
>
> It should then receive an acknowledgement, which will be a 32-byte md5
hash of
> the received message (which the smalltalk app can then verify). It's
possible the
> named pipe server may have gone away or otherwise been unable to deal with
> the request, and so I'd like to set a timeout on reading the
acknowledgement.
> I've tried using this:
>
> ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
onTimeout: [
> 'timeout'. ].
>
> and then made the pipe server pause artificially to test the code. But the
> smalltalk thread blocks on the read and doesn't carry on (even after the
> timeout), although if I then get the pipe server to send the correct
response
> (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
Obviously
> the timeout did what it's supposed to do, but couldn't 'unblock' the
blocking
> read on the pipe.
>
> Is there a way to accomplish this even with a blocking FileStream read?
I'd rather
> avoid a busy wait on there being 32 characters available if at all
possible.
>
> Thanks,
>
> Dave
>
>
>
> --
> View this message in context:
http://forum.world.st/Read-a-filestream-named-
> pipe-with-a-timeout-tp4735456.html
> Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML

dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

dsl101
In reply to this post by Ron Teitelbaum
OK - so I tried that and it still locks up the whole VM. Looks like thread-level fork isn't going to get me out of this one. Guess it's back to a busy loop, unless anyone has any ideas?


On Fri, Jan 10, 2014 at 12:12 PM, David Lomas <[hidden email]> wrote:
Hi Ron,

Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there), but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

start := DateAndTime millisecondClockValue.
(pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
(Delay forMilliseconds 50) wait.
]
pipe size = 32 ifTrue: [
"Get data"
] ifFalse: [
"Deal with timeout"
]

The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back. That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.

I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing I'll have to do something like this:
  • Set up a semaphore
  • Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
  • In the main thread, wait for up to 3 seconds for the semaphore to be signalled
  • If the semaphore times out, kill the forked process
Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?

Thanks,

Dave


On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
Hi Dave,

See #dataAvailable  and #recieveAvailableData.

It's never good to call for data if you don't know you have any.  Better to
setup a wait for data until call instead.  

All the best,

Ron Teitelbaum
Head Of Engineering
3d Immersive Collaboration Consulting
[hidden email]
Follow Me On Twitter: @RonTeitelbaum
www.3dicc.com
https://www.google.com/+3dicc


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of dsl101
> Sent: Thursday, January 09, 2014 10:16 AM
> To: [hidden email]
> Subject: [Newbies] Read a filestream (named pipe) with a timeout
>
> I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
> connection, which sends a message to the named pipe server with:
>
> msg := 'Here''s Johnny!!!!'.
> pipe nextPutAll: msg; flush.
>
> It should then receive an acknowledgement, which will be a 32-byte md5
hash of
> the received message (which the smalltalk app can then verify). It's
possible the
> named pipe server may have gone away or otherwise been unable to deal with
> the request, and so I'd like to set a timeout on reading the
acknowledgement.
> I've tried using this:
>
> ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
onTimeout: [
> 'timeout'. ].
>
> and then made the pipe server pause artificially to test the code. But the
> smalltalk thread blocks on the read and doesn't carry on (even after the
> timeout), although if I then get the pipe server to send the correct
response
> (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
Obviously
> the timeout did what it's supposed to do, but couldn't 'unblock' the
blocking
> read on the pipe.
>
> Is there a way to accomplish this even with a blocking FileStream read?
I'd rather
> avoid a busy wait on there being 32 characters available if at all
possible.
>
> Thanks,
>
> Dave
>
>
>
> --
> View this message in context:
http://forum.world.st/Read-a-filestream-named-
> pipe-with-a-timeout-tp4735456.html
> Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML


Levente Uzonyi-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

Levente Uzonyi-2
In reply to this post by dsl101
On Fri, 10 Jan 2014, dsl101 wrote:

> Hi Ron,
> Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there),
> but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

FileStreams don't have semaphores, so you can only use busy waiting with
them. However there's AsyncFile, which can do what you want. But its
interface is a bit cumbersome, and it's hardly tested/used at all. Here's
how it could work:

| syncSemaphore file message |
syncSemaphore := Semaphore new.
file := AsyncFile new.
file open: 'your_pipe' forWrite: true.
message := 'Here''s Johnny!!!!'.
file writeBuffer: message atFilePosition: 0 onCompletionDo: [
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
file readByteCount: 32 fromFilePosition: 0 onCompletionDo: [ :response |
  message := response.
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
Transcript show: 'Received: ', message; cr.
file close.

Using syncSemaphore is a must, because the callbacks are evaluated from
another process.


Levente

P.S.: If you want to communicate with another program from Squeak, then
you should use Sockets if possible, since those are versatile and well
tested.

>
> start := DateAndTime millisecondClockValue.
> (pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
> (Delay forMilliseconds 50) wait.
> ]
> pipe size = 32 ifTrue: [
> "Get data"
> ] ifFalse: [
> "Deal with timeout"
> ]
>
> The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back.
> That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.
>
> I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing
> I'll have to do something like this:
>  *  Set up a semaphore
>  *  Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
>  *  In the main thread, wait for up to 3 seconds for the semaphore to be signalled
>  *  If the semaphore times out, kill the forked process
> Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?
>
> Thanks,
>
> Dave
>
>
> On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
>       Hi Dave,
>
>       See #dataAvailable ??and #recieveAvailableData.
>
>       It's never good to call for data if you don't know you have any. ??Better to
>       setup a wait for data until call instead. ??
>
>       All the best,
>
>       Ron Teitelbaum
>       Head Of Engineering
>       3d Immersive Collaboration Consulting
>       [hidden email]
>       Follow Me On Twitter: @RonTeitelbaum
>       www.3dicc.com
>       https://www.google.com/+3dicc
>
>
>       > -----Original Message-----
>       > From: [hidden email] [mailto:[hidden email]
>       > [hidden email]] On Behalf Of dsl101
>       > Sent: Thursday, January 09, 2014 10:16 AM
>       > To: [hidden email]
>       > Subject: [Newbies] Read a filestream (named pipe) with a timeout
>       >
>       > I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
>       > connection, which sends a message to the named pipe server with:
>       >
>       > msg := 'Here''s Johnny!!!!'.
>       > pipe nextPutAll: msg; flush.
>       >
>       > It should then receive an acknowledgement, which will be a 32-byte md5
> hash of
> > the received message (which the smalltalk app can then verify). It's
> possible the
> > named pipe server may have gone away or otherwise been unable to deal with
> > the request, and so I'd like to set a timeout on reading the
> acknowledgement.
> > I've tried using this:
> >
> > ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
> onTimeout: [
> > 'timeout'. ].
> >
> > and then made the pipe server pause artificially to test the code. But the
> > smalltalk thread blocks on the read and doesn't carry on (even after the
> > timeout), although if I then get the pipe server to send the correct
> response
> > (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
> Obviously
> > the timeout did what it's supposed to do, but couldn't 'unblock' the
> blocking
> > read on the pipe.
> >
> > Is there a way to accomplish this even with a blocking FileStream read?
> I'd rather
> > avoid a busy wait on there being 32 characters available if at all
> possible.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Read-a-filestream-named-
> > pipe-with-a-timeout-tp4735456.html
> > Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
> To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
> NAML
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> View this message in context: Re: Read a filestream (named pipe) with a timeout Sent from the Squeak - Beginners mailing list archive at Nabble.com.
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

dsl101
Thanks - I'm persevering with the busy wait for now, but may look at async. I also thought it looked much trickier, but your example code is great so thanks for that.

I did originally try using sockets, but it triggers all kinds of security warnings on a PC when a socket server is set up. I didn't want to worry end users, or required them to put exceptions in their firewalls, etc., when the communication is entirely local. I have also tried using plain files (which works), but watching for changes on the filesystem is ugly and prone to missing things.

Ideally, I'd like to use messages (e.g. via WndProc on Win32). In fact, I've been able to send windows messages from Squeak to a vb.net app by calling RegisterWindowMessage / SendMessage in user32.dll, but I couldn't find any way of receiving messages using this system, and I need bi-directional. I presume the VM would need to capture and pass those on to the Squeak image, which it doesn't currently do. If there is some kind of 'user' event channel I could use, please do suggest something...

Hence pipes was the least worst option so far.

Thanks again,

Dave


On Fri, Jan 10, 2014 at 3:37 PM, Levente Uzonyi-2 [via Smalltalk] <[hidden email]> wrote:
On Fri, 10 Jan 2014, dsl101 wrote:

> Hi Ron,
> Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there),
> but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

FileStreams don't have semaphores, so you can only use busy waiting with
them. However there's AsyncFile, which can do what you want. But its
interface is a bit cumbersome, and it's hardly tested/used at all. Here's
how it could work:

| syncSemaphore file message |
syncSemaphore := Semaphore new.
file := AsyncFile new.
file open: 'your_pipe' forWrite: true.
message := 'Here''s Johnny!!!!'.
file writeBuffer: message atFilePosition: 0 onCompletionDo: [
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
file readByteCount: 32 fromFilePosition: 0 onCompletionDo: [ :response |
  message := response.
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
Transcript show: 'Received: ', message; cr.
file close.

Using syncSemaphore is a must, because the callbacks are evaluated from
another process.


Levente

P.S.: If you want to communicate with another program from Squeak, then
you should use Sockets if possible, since those are versatile and well
tested.

>
> start := DateAndTime millisecondClockValue.
> (pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
> (Delay forMilliseconds 50) wait.
> ]
> pipe size = 32 ifTrue: [
> "Get data"
> ] ifFalse: [
> "Deal with timeout"
> ]
>
> The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back.
> That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.
>
> I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing
> I'll have to do something like this:
>  *  Set up a semaphore
>  *  Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
>  *  In the main thread, wait for up to 3 seconds for the semaphore to be signalled
>  *  If the semaphore times out, kill the forked process
> Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?
>
> Thanks,
>
> Dave
>
>
> On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
>       Hi Dave,
>
>       See #dataAvailable ??and #recieveAvailableData.
>
>       It's never good to call for data if you don't know you have any. ??Better to
>       setup a wait for data until call instead. ??
>

>       All the best,
>
>       Ron Teitelbaum
>       Head Of Engineering
>       3d Immersive Collaboration Consulting
>       [hidden email]
>       Follow Me On Twitter: @RonTeitelbaum
>       www.3dicc.com
>       https://www.google.com/+3dicc
>
>
>       > -----Original Message-----
>       > From: [hidden email] [mailto:[hidden email]

>       > [hidden email]] On Behalf Of dsl101
>       > Sent: Thursday, January 09, 2014 10:16 AM
>       > To: [hidden email]
>       > Subject: [Newbies] Read a filestream (named pipe) with a timeout
>       >
>       > I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
>       > connection, which sends a message to the named pipe server with:
>       >
>       > msg := 'Here''s Johnny!!!!'.
>       > pipe nextPutAll: msg; flush.
>       >
>       > It should then receive an acknowledgement, which will be a 32-byte md5
> hash of
> > the received message (which the smalltalk app can then verify). It's
> possible the
> > named pipe server may have gone away or otherwise been unable to deal with
> > the request, and so I'd like to set a timeout on reading the
> acknowledgement.
> > I've tried using this:
> >
> > ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
> onTimeout: [
> > 'timeout'. ].
> >
> > and then made the pipe server pause artificially to test the code. But the
> > smalltalk thread blocks on the read and doesn't carry on (even after the
> > timeout), although if I then get the pipe server to send the correct
> response
> > (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
> Obviously
> > the timeout did what it's supposed to do, but couldn't 'unblock' the
> blocking
> > read on the pipe.
> >
> > Is there a way to accomplish this even with a blocking FileStream read?
> I'd rather
> > avoid a busy wait on there being 32 characters available if at all
> possible.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Read-a-filestream-named-
> > pipe-with-a-timeout-tp4735456.html
> > Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
> To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
> NAML
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> View this message in context: Re: Read a filestream (named pipe) with a timeout Sent from the Squeak - Beginners mailing list archive at Nabble.com.
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735726.html
To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML

dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

dsl101
In reply to this post by Levente Uzonyi-2
And here's another one I'm banging my head on. If I open 2 named pipes like so:

pipeIn := FileStream fileNamed: '\\.\pipe\in'.
pipeOut := FileStream fileNamed: '\\.\pipe\out'.

And test them like this:
  1. Write 'Here's Johnny!!!!!' to pipeOut
  2. Wait for the md5 ack from the pipe server and verify
  3. Wait for a message from the pipe server on pipeIn
  4. Computer md5 ack and send it back
all works fine (assuming the pipe server at the other end has a mirror image of this flow, which it does).

However, if I do this (simulating having several messages waiting in the 'out' pipe):
  1. Write 'Here's Johnny!!!!!' to pipeOut (call this message 1)
  2. Write 'Another message' to pipeOut (call this message 2)
  3. Wait for the md5 ack for message 1 and verify (pipe server only reads message 1)
  4. Wait for a message from the pipe server on pipeIn (pipe server initiates this once it has sent the ack above)
  5. Computer md5 and send it back via pipeIn
I get a 'write failed' at step 5, trying to send the md5 back on pipeIn. This seems strange, since the only difference I can see is the extra write to pipeOut at step 2 - nothing to do with pipeIn.

What's even more frustrating is that by step 3, I can see on the pipe server (via PeekNamedPipe) that there are another 15 bytes available (message 2), and if I actually read them here before sending the ack back to the Squeak app, then step 5 doesn't fail. Gah... Can a nextPutAll: on one StandardFileStream fail because a write on another hasn't been read? The full code looks like this:

pipeIn := FileStream fileNamed: '\\.\pipe\in'.
pipeOut := FileStream fileNamed: '\\.\pipe\out'.

msg := 'Here''s Johnny!!!!'.
msgHash := ((CMD5Hasher hashMessage: msg) printStringBase: 16 length: 32 padded: true) asLowercase.
pipeOut nextPutAll: msg; flush.

"Queue another message - this will cause the later call to pipeIn nextPutAll: to fail, unless the pipe server has already read this message..." 
msg := 'Another message'.
pipeOut nextPutAll: msg; flush.

start := DateAndTime millisecondClockValue.
[(pipeOut size < 32) & ((DateAndTime millisecondClockValue) - start < 3000)] whileTrue: [
(Delay forMilliseconds: 200) wait.
].
pipeOut size = 32 ifTrue: [
ack := pipeOut next: 32.
] ifFalse: [
ack := 'timeout'.
].
ack = msgHash ifFalse: [
^ false.
].

"Wait up to 3 seconds for the return connection check from pipe server"
start := DateAndTime millisecondClockValue.
[(pipeIn size = 0) & ((DateAndTime millisecondClockValue) - start < 3000)] whileTrue: [
(Delay forMilliseconds: 200) wait.
].
msg := pipeIn next: (pipeIn size).
msgHash := ((CMD5Hasher hashMessage: msg) printStringBase: 16 length: 32 padded: true) asLowercase.
"The next line will fail unless the pipe server has read our earlier message on pipeOut"
pipeIn nextPutAll: msgHash; flush.
^ true.

BTW - the reason I'm using 2 pipes is that both ends (the squeak app and the vb.net app) could generate events / messages at any time, and so I need both ends to be 'waiting' for a message from the other. This seemed the simplest way to achieve this and be able to send an ack without the risk of the ack getting mangled up with new messages. However, it seems like I might have been wrong...


On Fri, Jan 10, 2014 at 4:25 PM, David Lomas <[hidden email]> wrote:
Thanks - I'm persevering with the busy wait for now, but may look at async. I also thought it looked much trickier, but your example code is great so thanks for that.

I did originally try using sockets, but it triggers all kinds of security warnings on a PC when a socket server is set up. I didn't want to worry end users, or required them to put exceptions in their firewalls, etc., when the communication is entirely local. I have also tried using plain files (which works), but watching for changes on the filesystem is ugly and prone to missing things.

Ideally, I'd like to use messages (e.g. via WndProc on Win32). In fact, I've been able to send windows messages from Squeak to a vb.net app by calling RegisterWindowMessage / SendMessage in user32.dll, but I couldn't find any way of receiving messages using this system, and I need bi-directional. I presume the VM would need to capture and pass those on to the Squeak image, which it doesn't currently do. If there is some kind of 'user' event channel I could use, please do suggest something...

Hence pipes was the least worst option so far.

Thanks again,

Dave


On Fri, Jan 10, 2014 at 3:37 PM, Levente Uzonyi-2 [via Smalltalk] <[hidden email]> wrote:
On Fri, 10 Jan 2014, dsl101 wrote:

> Hi Ron,
> Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there),
> but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

FileStreams don't have semaphores, so you can only use busy waiting with
them. However there's AsyncFile, which can do what you want. But its
interface is a bit cumbersome, and it's hardly tested/used at all. Here's
how it could work:

| syncSemaphore file message |
syncSemaphore := Semaphore new.
file := AsyncFile new.
file open: 'your_pipe' forWrite: true.
message := 'Here''s Johnny!!!!'.
file writeBuffer: message atFilePosition: 0 onCompletionDo: [
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
file readByteCount: 32 fromFilePosition: 0 onCompletionDo: [ :response |
  message := response.
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
Transcript show: 'Received: ', message; cr.
file close.

Using syncSemaphore is a must, because the callbacks are evaluated from
another process.


Levente

P.S.: If you want to communicate with another program from Squeak, then
you should use Sockets if possible, since those are versatile and well
tested.

>
> start := DateAndTime millisecondClockValue.
> (pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
> (Delay forMilliseconds 50) wait.
> ]
> pipe size = 32 ifTrue: [
> "Get data"
> ] ifFalse: [
> "Deal with timeout"
> ]
>
> The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back.
> That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.
>
> I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing
> I'll have to do something like this:
>  *  Set up a semaphore
>  *  Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
>  *  In the main thread, wait for up to 3 seconds for the semaphore to be signalled
>  *  If the semaphore times out, kill the forked process
> Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?
>
> Thanks,
>
> Dave
>
>
> On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
>       Hi Dave,
>
>       See #dataAvailable ??and #recieveAvailableData.
>
>       It's never good to call for data if you don't know you have any. ??Better to
>       setup a wait for data until call instead. ??
>

>       All the best,
>
>       Ron Teitelbaum
>       Head Of Engineering
>       3d Immersive Collaboration Consulting
>       [hidden email]
>       Follow Me On Twitter: @RonTeitelbaum
>       www.3dicc.com
>       https://www.google.com/+3dicc
>
>
>       > -----Original Message-----
>       > From: [hidden email] [mailto:[hidden email]

>       > [hidden email]] On Behalf Of dsl101
>       > Sent: Thursday, January 09, 2014 10:16 AM
>       > To: [hidden email]
>       > Subject: [Newbies] Read a filestream (named pipe) with a timeout
>       >
>       > I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
>       > connection, which sends a message to the named pipe server with:
>       >
>       > msg := 'Here''s Johnny!!!!'.
>       > pipe nextPutAll: msg; flush.
>       >
>       > It should then receive an acknowledgement, which will be a 32-byte md5
> hash of
> > the received message (which the smalltalk app can then verify). It's
> possible the
> > named pipe server may have gone away or otherwise been unable to deal with
> > the request, and so I'd like to set a timeout on reading the
> acknowledgement.
> > I've tried using this:
> >
> > ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
> onTimeout: [
> > 'timeout'. ].
> >
> > and then made the pipe server pause artificially to test the code. But the
> > smalltalk thread blocks on the read and doesn't carry on (even after the
> > timeout), although if I then get the pipe server to send the correct
> response
> > (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
> Obviously
> > the timeout did what it's supposed to do, but couldn't 'unblock' the
> blocking
> > read on the pipe.
> >
> > Is there a way to accomplish this even with a blocking FileStream read?
> I'd rather
> > avoid a busy wait on there being 32 characters available if at all
> possible.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Read-a-filestream-named-
> > pipe-with-a-timeout-tp4735456.html
> > Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
> To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
> NAML
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> View this message in context: Re: Read a filestream (named pipe) with a timeout Sent from the Squeak - Beginners mailing list archive at Nabble.com.
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735726.html
To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML


dsl101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

dsl101
In reply to this post by Levente Uzonyi-2
Levente,

I gave it a try with the AsyncFile method you outlined, and I hit 2 problems:

1. The named pipe is created in Message mode, but repeated calls to writeBuffer:atFilePosition:onCompletionDo: seem to concatenate all the messages together - I couldn't see the equivalent of 'flush' for FileStream which separates out the messages at the pipe server end.
2. I couldn't find the equivalent of 'size' from FileStream to find out how much data was available in the next message when reading - readByteCount:fromFilePosition:onCompletionDo: seems to want me to pass this value in. Given that the messages vary in size, this is a little awkward (although I guess I could make it send a fixed 256-byte message each time, that is bound to bite me later (640kb is enough for anyone, etc.)).

Anyway, if you have any other thoughts on using AsyncFile, or an alternative, I'd be most grateful.

Many thanks,

David.


On Fri, Jan 10, 2014 at 3:37 PM, Levente Uzonyi-2 [via Smalltalk] <[hidden email]> wrote:
On Fri, 10 Jan 2014, dsl101 wrote:

> Hi Ron,
> Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there),
> but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

FileStreams don't have semaphores, so you can only use busy waiting with
them. However there's AsyncFile, which can do what you want. But its
interface is a bit cumbersome, and it's hardly tested/used at all. Here's
how it could work:

| syncSemaphore file message |
syncSemaphore := Semaphore new.
file := AsyncFile new.
file open: 'your_pipe' forWrite: true.
message := 'Here''s Johnny!!!!'.
file writeBuffer: message atFilePosition: 0 onCompletionDo: [
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
file readByteCount: 32 fromFilePosition: 0 onCompletionDo: [ :response |
  message := response.
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
Transcript show: 'Received: ', message; cr.
file close.

Using syncSemaphore is a must, because the callbacks are evaluated from
another process.


Levente

P.S.: If you want to communicate with another program from Squeak, then
you should use Sockets if possible, since those are versatile and well
tested.

>
> start := DateAndTime millisecondClockValue.
> (pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
> (Delay forMilliseconds 50) wait.
> ]
> pipe size = 32 ifTrue: [
> "Get data"
> ] ifFalse: [
> "Deal with timeout"
> ]
>
> The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back.
> That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.
>
> I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing
> I'll have to do something like this:
>  *  Set up a semaphore
>  *  Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
>  *  In the main thread, wait for up to 3 seconds for the semaphore to be signalled
>  *  If the semaphore times out, kill the forked process
> Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?
>
> Thanks,
>
> Dave
>
>
> On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
>       Hi Dave,
>
>       See #dataAvailable ??and #recieveAvailableData.
>
>       It's never good to call for data if you don't know you have any. ??Better to
>       setup a wait for data until call instead. ??
>

>       All the best,
>
>       Ron Teitelbaum
>       Head Of Engineering
>       3d Immersive Collaboration Consulting
>       [hidden email]
>       Follow Me On Twitter: @RonTeitelbaum
>       www.3dicc.com
>       https://www.google.com/+3dicc
>
>
>       > -----Original Message-----
>       > From: [hidden email] [mailto:[hidden email]

>       > [hidden email]] On Behalf Of dsl101
>       > Sent: Thursday, January 09, 2014 10:16 AM
>       > To: [hidden email]
>       > Subject: [Newbies] Read a filestream (named pipe) with a timeout
>       >
>       > I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
>       > connection, which sends a message to the named pipe server with:
>       >
>       > msg := 'Here''s Johnny!!!!'.
>       > pipe nextPutAll: msg; flush.
>       >
>       > It should then receive an acknowledgement, which will be a 32-byte md5
> hash of
> > the received message (which the smalltalk app can then verify). It's
> possible the
> > named pipe server may have gone away or otherwise been unable to deal with
> > the request, and so I'd like to set a timeout on reading the
> acknowledgement.
> > I've tried using this:
> >
> > ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
> onTimeout: [
> > 'timeout'. ].
> >
> > and then made the pipe server pause artificially to test the code. But the
> > smalltalk thread blocks on the read and doesn't carry on (even after the
> > timeout), although if I then get the pipe server to send the correct
> response
> > (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
> Obviously
> > the timeout did what it's supposed to do, but couldn't 'unblock' the
> blocking
> > read on the pipe.
> >
> > Is there a way to accomplish this even with a blocking FileStream read?
> I'd rather
> > avoid a busy wait on there being 32 characters available if at all
> possible.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Read-a-filestream-named-
> > pipe-with-a-timeout-tp4735456.html
> > Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
> To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
> NAML
>
>
> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> View this message in context: Re: Read a filestream (named pipe) with a timeout Sent from the Squeak - Beginners mailing list archive at Nabble.com.
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735726.html
To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML

Ron Teitelbaum
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Read a filestream (named pipe) with a timeout

Ron Teitelbaum

Hi David,

 

Go back to sockets.  The pain you are experiencing is not worth saving the user from answering a firewall warning that nobody pays attention to.

 

FWIW,

 

Ron

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of dsl101
Sent: Monday, January 13, 2014 11:16 AM
To: [hidden email]
Subject: [Newbies] Re: Read a filestream (named pipe) with a timeout

 

Levente,

 

I gave it a try with the AsyncFile method you outlined, and I hit 2 problems:

 

1. The named pipe is created in Message mode, but repeated calls to writeBuffer:atFilePosition:onCompletionDo: seem to concatenate all the messages together - I couldn't see the equivalent of 'flush' for FileStream which separates out the messages at the pipe server end.

2. I couldn't find the equivalent of 'size' from FileStream to find out how much data was available in the next message when reading - readByteCount:fromFilePosition:onCompletionDo: seems to want me to pass this value in. Given that the messages vary in size, this is a little awkward (although I guess I could make it send a fixed 256-byte message each time, that is bound to bite me later (640kb is enough for anyone, etc.)).

 

Anyway, if you have any other thoughts on using AsyncFile, or an alternative, I'd be most grateful.

 

Many thanks,

 

David.

 

On Fri, Jan 10, 2014 at 3:37 PM, Levente Uzonyi-2 [via Smalltalk] <[hidden email]> wrote:

On Fri, 10 Jan 2014, dsl101 wrote:

> Hi Ron,
> Thanks for that - but I can only see #dataAvailable for Sockets, not for FileStream (named pipes). I think the same kind of thing is available for pipes (you can do `pipe size` to see how much data is there),
> but it still doesn't wait. I'm trying to avoid a busy loop waiting for the data - like this:

FileStreams don't have semaphores, so you can only use busy waiting with
them. However there's AsyncFile, which can do what you want. But its
interface is a bit cumbersome, and it's hardly tested/used at all. Here's
how it could work:

| syncSemaphore file message |
syncSemaphore := Semaphore new.
file := AsyncFile new.
file open: 'your_pipe' forWrite: true.
message := 'Here''s Johnny!!!!'.
file writeBuffer: message atFilePosition: 0 onCompletionDo: [
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
file readByteCount: 32 fromFilePosition: 0 onCompletionDo: [ :response |
  message := response.
  syncSemaphore signal ].
(syncSemaphore waitTimeoutMSecs: 3000) ifTrue: [
  "handle timeout" ].
Transcript show: 'Received: ', message; cr.
file close.

Using syncSemaphore is a must, because the callbacks are evaluated from
another process.


Levente

P.S.: If you want to communicate with another program from Squeak, then
you should use Sockets if possible, since those are versatile and well
tested.


>
> start := DateAndTime millisecondClockValue.
> (pipe size < 32) & (DateAndTime millisecondClockValue - start < 3000) ifTrue: [
> (Delay forMilliseconds 50) wait.
> ]
> pipe size = 32 ifTrue: [
> "Get data"
> ] ifFalse: [
> "Deal with timeout"
> ]
>
> The shorter the 'wait', the more responsive the code is to data arriving on the pipe, but the more CPU it will use as it spins round the loop. The longer the 'wait', the more lag it has for data coming back.
> That's what I'm trying to avoid by blocking on the read, but with a way to escape after some timeout.
>
> I'm guessing the call to 'pipe next:' is a primitive, and blocks there, which is why valueWithin:onTimeout: doesn't return after the timeout, but does eventually return the correct answer. So, I'm guessing
> I'll have to do something like this:

>  *  Set up a semaphore
>  *  Fork the blocking read process, which will signal the semaphore if it ever returns its 32 bytes
>  *  In the main thread, wait for up to 3 seconds for the semaphore to be signalled
>  *  If the semaphore times out, kill the forked process

> Obviously there's a potential race at the end there, but the worst case is we throw away data which was returned at the last moment. Is there anything else you can see wrong with this approach?
>
> Thanks,
>
> Dave
>
>

> On Thu, Jan 9, 2014 at 9:16 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> wrote:
>       Hi Dave,
>

>       See #dataAvailable ??and #recieveAvailableData.
>
>       It's never good to call for data if you don't know you have any. ??Better to
>       setup a wait for data until call instead. ??

>


>       All the best,
>
>       Ron Teitelbaum
>       Head Of Engineering
>       3d Immersive Collaboration Consulting
>       [hidden email]
>       Follow Me On Twitter: @RonTeitelbaum
>       www.3dicc.com
>       https://www.google.com/+3dicc
>
>
>       > -----Original Message-----

>       > From: [hidden email] [mailto:[hidden email]


>       > [hidden email]] On Behalf Of dsl101
>       > Sent: Thursday, January 09, 2014 10:16 AM
>       > To: [hidden email]
>       > Subject: [Newbies] Read a filestream (named pipe) with a timeout
>       >
>       > I'm using Squeak 4.2 and working on the smalltalk end of a named pipe
>       > connection, which sends a message to the named pipe server with:
>       >
>       > msg := 'Here''s Johnny!!!!'.
>       > pipe nextPutAll: msg; flush.
>       >
>       > It should then receive an acknowledgement, which will be a 32-byte md5
> hash of
> > the received message (which the smalltalk app can then verify). It's
> possible the
> > named pipe server may have gone away or otherwise been unable to deal with
> > the request, and so I'd like to set a timeout on reading the
> acknowledgement.
> > I've tried using this:
> >
> > ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3)
> onTimeout: [
> > 'timeout'. ].
> >
> > and then made the pipe server pause artificially to test the code. But the
> > smalltalk thread blocks on the read and doesn't carry on (even after the
> > timeout), although if I then get the pipe server to send the correct
> response
> > (after a 5 second delay, for example), the value of 'ack' is 'timeout'.
> Obviously
> > the timeout did what it's supposed to do, but couldn't 'unblock' the
> blocking
> > read on the pipe.
> >
> > Is there a way to accomplish this even with a blocking FileStream read?
> I'd rather
> > avoid a busy wait on there being 32 characters available if at all
> possible.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Read-a-filestream-named-
> > pipe-with-a-timeout-tp4735456.html
> > Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>

> ________________________________________________________________________________________________________________________________________________________________________________________________________________

> If you reply to this email, your message will be added to the discussion below:
> http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735547.html
> To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
> NAML
>
>

> ________________________________________________________________________________________________________________________________________________________________________________________________________________
> View this message in context: Re: Read a filestream (named pipe) with a timeout Sent from the Squeak - Beginners mailing list archive at Nabble.com.
>

_______________________________________________

Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735726.html

To unsubscribe from Read a filestream (named pipe) with a timeout, click here.
NAML

 

 

View this message in context: Re: Read a filestream (named pipe) with a timeout
Sent from the Squeak - Beginners mailing list archive at Nabble.com.


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Free forum by Nabble Edit this page