On Mon, 18 Feb 2013 14:36:33 -0600 Jim Ursetto <zbignie...@gmail.com> wrote:
> On Feb 18, 2013, at 3:58 AM, J Altfas wrote:
>
> > 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.
>
> It's probably not an oversight, just that as Felix said there was probably no
> usleep(3) in Windows and the equivalent was never implemented. Also since
> file-select works, there was probably no impetus to fix it.
>
> I would be ok with adding usleep to the posix-extras egg if you want. I'm
> not sure if it should be a separate function or just override (sleep) to
> accept fractional values. I'm thinking the latter. I would ideally want to
> get it to work on Windows, maybe using John Cowan's suggestion (which gives
> at most millisecond precision, so "usleep" is not a good name) or
> QueryPerformanceCounter (?). By the way, on Windows, (sleep t) is currently
> implemented as Sleep(t*1000), but the argument is artificially constrained to
> be an integer.
>
> If you just want a direct interface to usleep, I would honestly just wrap it
> in a foreign-lambda in your code as you suggested. I don't think it's a bad
> approach.
That's what I did, but it would make things a lot simpler if it were not
necessary to go though contortions to achieve cross-platform functionality.
Yeah, Windows has API incompatibilities with many other platforms. However,
Window's sleep has more or less millisec resolution. To the extent it lacks
precision, on most platforms timing functions are usually approximate anyway,
it's just how much and what direction that evokes controversy among OS
developers.
For Chicken's purposes, maybe a compromise would be to define a procedure
'(millisleep millisec), which could be implemented on Windows and posix
platforms. On Windows, a millisec parameter could be past directly to sleep
(sleep tm-in-msec) instead of (sleep (* secs 1000)). On posix, millisecs would
be (usleep (* ms 1000)).
FWIW, just to make it more fun, posix is promoting nanosleep in preference to
usleep, but the latter isn't disappearing either, so safe enough to rely on it.
> > 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.
>
> Yes, erroneous warnings should definitely be fixed. I didn't intend to
> address that in my reply. file-select is actually a reasonable solution if
> you want a blocking sub-second sleep, although it too doesn't work on Windows.
Yup, select won't work on Windows as a sleep function, since Windows select
errors out if all FD_SETS are NULL, which is how it's done on posix systems.
It occurs to me as little as I know about Windows, I've no idea at all about
OSx, perhaps it presents a different set of complications altogether.
> Jim
Thanks,
J. Altfas
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
