Re: [Chicken-users] (file-select ...) and compiler warnings

[J Altfas]

On Sun, 17 Feb 2013 21:16:56 -0600 Jim Ursetto <address@hidden> wrote

> On Feb 17, 2013, at 4:18 PM, J Altfas wrote:
>
> > Hello,
> >
> > Using 'file-select' as a sub-second sleep procedure works without hitch under csi:
> >
> > (define (sleeper tm)
> > (let ((currms (current-milliseconds)))
> > (let-values (((_ __) (file-select #f #f tm)))
> > (print (- (current-milliseconds) currms)))))
> >
> > ;1> (sleeper 0.05)
> > 50.0
>

> Perhaps better is to use thread-sleep!, which does a select or poll behind the scenes, but does not block other threads. file-select will block all threads until the timeout occurs.

Of course I considered 'thread-sleep!', but decided against using it. Since my application was not srfi-18 threaded, thread-sleep! would be an expensive way to get to the underlying select, which as you said is down there somewhere under the hood. Running a single-threaded program, I wasn't worried about blocking other threads.

> (use srfi-18)
> (define (sleeper tm)
> (let ((currms (current-milliseconds)))
> (thread-sleep! tm)
> (print (- (current-milliseconds) currms))))
>
> You can test this by running a thread in the background:
>
> (thread-start! (lambda () (let lp () (print 'ping) (thread-sleep! 2) (lp))))
> (sleeper 5.5)

Indeed, in a multi-threaded context taking care not to block other threads is important, and your revised version is perfectly sensible. But if no threads are started I think the optimum approach might be different.

> > Of course, having a "real" usleep function would be cleaner than faking it with file-select, especially as implementing a usleep procedure is pretty trivial:
> >
> > (define usleep (foreign-lambda int "usleep" unsigned-integer32))
>
> I don't know why sleep(3) was implemented in the posix unit and usleep(3) was not. thread-sleep! is preferable to either, though, in my opinion.

Certainly agree that leaving out usleep was an oversight, considering how simple it is to include it. While I'm pretty sure many of the posix functions are not optimum in an srfi-18 threaded environment, file-select, sleep, and friends are still part of Chicken for good reasons. In that sense, I don't think thread-sleep! would be a universal drop-in replacement for posix usleep, et. al.

As long as file-select is available in Chicken, people are going to have uses for it. As it is, the current types.db declaration for file-select produces several warnings. I was a little concerned the warnings might be distressing for new Chicken users, though more a matter of technical details than truly having dire consequences for the compiled output.

> Jim

Appreciate your thoughts on the subject and the many contributions you've made to Chicken.

J Altfas