Re: [Chicken-users] (file-select ...) and compiler warnings
Jim Ursetto scripsit: 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. +1. Conceptually, a sleep duration is inherently inexact, and it makes sense to model it with an inexact number. -- In politics, obedience and support John Cowan co...@ccil.org are the same thing. --Hannah Arendthttp://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (file-select ...) and compiler warnings
On Sun, 17 Feb 2013 21:16:56 -0600 Jim Ursetto zbignie...@gmail.com 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 ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (file-select ...) and compiler warnings
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. I think usleep(3) is not available on Windows. There is probably a win32 equivalent, though. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (file-select ...) and compiler warnings
Felix scripsit: I think usleep(3) is not available on Windows. There is probably a win32 equivalent, though. The Woe32 version is Sleep(), which accepts an argument in milliseconds, and puts the current Windows thread to sleep. However, the default resolution is 10-15 ms. If you want to change this, you have to call timeBeginPeriod(1) at the beginning of the application and timeEndPeriod(1) at the end. -- So they play that [tune] on John Cowan their fascist banjos, eh? co...@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (file-select ...) and compiler warnings
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
Re: [Chicken-users] (file-select ...) and compiler warnings
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. 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. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (file-select ...) and compiler warnings
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. (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) 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. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
