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

Fri Jan 10 12:45:14 UTC 2014

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 <dl3 at pale-eds.co.uk> 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] <
> ml-node+s1294792n4735547h61 at n4.nabble.com> 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] <http://user/SendEmail.jtp?type=node&node=4735547&i=0>
>> Follow Me On Twitter: @RonTeitelbaum
>> www.3dicc.com
>> https://www.google.com/+3dicc
>>
>>
>> > -----Original Message-----
>> > From: [hidden email]<http://user/SendEmail.jtp?type=node&node=4735547&i=1>[mailto:
>> beginners-
>> > [hidden email] <http://user/SendEmail.jtp?type=node&node=4735547&i=2>]
>> On Behalf Of dsl101
>> > Sent: Thursday, January 09, 2014 10:16 AM
>> > To: [hidden email]<http://user/SendEmail.jtp?type=node&node=4735547&i=3>
>> > 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://user/SendEmail.jtp?type=node&node=4735547&i=4>
>> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> [hidden email] <http://user/SendEmail.jtp?type=node&node=4735547&i=5>
>> 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<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4735456&code=ZGwzQHBhbGUtZWRzLmNvLnVrfDQ3MzU0NTZ8MTEyNTU4NzUzMg==>
>> .
>> NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.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>
>>
>
>

--
View this message in context: http://forum.world.st/Read-a-filestream-named-pipe-with-a-timeout-tp4735456p4735669.html
Sent from the Squeak - Beginners mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20140110/f17c8745/attachment-0001.htm