[Newbies] Re: Read a filestream (named pipe) with a timeout

Ron Teitelbaum ron at usmedrec.com
Mon Jan 13 17:01:47 UTC 2014


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: beginners-bounces at lists.squeakfoundation.org
[mailto:beginners-bounces at lists.squeakfoundation.org] On Behalf Of dsl101
Sent: Monday, January 13, 2014 11:16 AM
To: beginners at lists.squeakfoundation.org
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-tp4735456p
4735547.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://user/SendEmail.jtp?type=node&node=4735726&i=0>  
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-tp4735456p
4735726.html 

To unsubscribe from Read a filestream (named pipe) with a timeout, click
here.
 
<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan
t_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabb
le.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&
breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble
%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML 

 

 

  _____  

View this message in context: Re: Read a filestream (named pipe) with a
timeout
<http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456
p4736412.html> 
Sent from the Squeak - Beginners mailing list archive
<http://forum.world.st/Squeak-Beginners-f107673.html>  at Nabble.com.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20140113/619c64ad/attachment-0001.htm


More information about the Beginners mailing list