Is there a timer function in cmucl? I want to call a function
periodically and in a separate thread. Looking at the "mp" package I do
not see something like "make-timer"..
--
vedm
>>>>> "vedm" == vedm <··@nospam.com> writes:
vedm> Is there a timer function in cmucl? I want to call a function
vedm> periodically and in a separate thread. Looking at the "mp" package I do
vedm> not see something like "make-timer"..
It's possible to use sigalrm, but I've never used the MP package.
Note that CMUCL is not interrupt-safe, so having interrupts go off
periodically is a good way to trash your lisp.
Ray
Raymond Toy <···········@ericsson.com> writes:
> >>>>> "vedm" == vedm <··@nospam.com> writes:
>
> vedm> Is there a timer function in cmucl? I want to call a function
> vedm> periodically and in a separate thread. Looking at the "mp" package I do
> vedm> not see something like "make-timer"..
>
> It's possible to use sigalrm, but I've never used the MP package.
>
> Note that CMUCL is not interrupt-safe, so having interrupts go off
> periodically is a good way to trash your lisp.
(ab)Using SERVE-EVENT should be safe, though. Write a very small
utility application that writes to a pipe every N seconds, and put an
fd-handler on that pipe.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Raymond Toy <···········@ericsson.com> writes:
>
> > >>>>> "vedm" == vedm <··@nospam.com> writes:
> >
> > vedm> Is there a timer function in cmucl? I want to call a function
> > vedm> periodically and in a separate thread. Looking at the "mp" package I do
> > vedm> not see something like "make-timer"..
> >
> > It's possible to use sigalrm, but I've never used the MP package.
> >
> > Note that CMUCL is not interrupt-safe, so having interrupts go off
> > periodically is a good way to trash your lisp.
>
> (ab)Using SERVE-EVENT should be safe, though. Write a very small
> utility application that writes to a pipe every N seconds, and put an
> fd-handler on that pipe.
thanks, I'll try this.
--
vedm
Raymond Toy <···········@ericsson.com> writes:
> >>>>> "vedm" == vedm <··@nospam.com> writes:
>
> vedm> Is there a timer function in cmucl? I want to call a function
> vedm> periodically and in a separate thread. Looking at the "mp" package I do
> vedm> not see something like "make-timer"..
>
> It's possible to use sigalrm, but I've never used the MP package.
>
> Note that CMUCL is not interrupt-safe, so having interrupts go off
> periodically is a good way to trash your lisp.
That sounds really bad. So in other words the mp package in cmucl is
fake and I shouldn't use it? I guess I will try sbcl: I found this timer
package for sbcl: http://www.xach.com/lisp/timer/doc.html.
The other option would be to pay 1000$ for ACL, but knowing that Java is
free, I rather wouldn't.
--
vedm
Raymond Toy schrieb:
>>>>>>"vedm" == vedm <··@nospam.com> writes:
>
>
> vedm> Is there a timer function in cmucl? I want to call a function
> vedm> periodically and in a separate thread. Looking at the "mp" package I do
> vedm> not see something like "make-timer"..
>
> It's possible to use sigalrm, but I've never used the MP package.
>
> Note that CMUCL is not interrupt-safe, so having interrupts go off
> periodically is a good way to trash your lisp.
What does this mean? "Not interrupt-safe"?
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Raymond Toy schrieb:
> >>>>>>"vedm" == vedm <··@nospam.com> writes:
> > vedm> Is there a timer function in cmucl? I want to call a
> > function
> > vedm> periodically and in a separate thread. Looking at the "mp" package I do
> > vedm> not see something like "make-timer"..
> > It's possible to use sigalrm, but I've never used the MP package.
> > Note that CMUCL is not interrupt-safe, so having interrupts go off
> > periodically is a good way to trash your lisp.
>
> What does this mean? "Not interrupt-safe"?
You would expect that a Lisp function could be registered as an
interrupt handler. This works by having the Lisp implementation
provide the real interrupt handler, which in turn properly arranges
the system for the registered Lisp function to be called, work normally,
and for it to return. (That's what Lisp did in the early 1970s.)
I took Raymond's comment to mean that CMUCL is _not_ such a Lisp
implementation. There is an interface directly to the underlying
Unix signal calls, and you can get a Lisp function invoked.
But things have not been properly arranged to ensure that the
stack and other internal data structures and functions are
preserved correctly. Maybe you'll get lucky, but maybe the entire
Lisp implemenation will go ka-blooey. If that's truly what was meant,
that would be a pretty sad state of affairs.
Someone who knows what CMUCL actually does will have to clarify.
ANSI Common Lisp doesn't acknowledge that threads, interrupts,
or anything like that exists, of course.
The commercial Lisp implementations provide multiprocessing
(threading) primitives such as timers, which work the way
you would expect.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Andr� Thieme <······························@justmail.de> writes:
>
[..]
> ANSI Common Lisp doesn't acknowledge that threads, interrupts,
> or anything like that exists, of course.
I started using Lisp only recently and the fact that the standard omits
such essential features is my biggest gripe with this otherwise wonderful
language. I really don't understand why nothing is done about it.
--
vedm
vedm <··@nospam.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Andr� Thieme <······························@justmail.de> writes:
> >
>
> [..]
>
> > ANSI Common Lisp doesn't acknowledge that threads, interrupts,
> > or anything like that exists, of course.
>
> I started using Lisp only recently and the fact that the standard omits
> such essential features is my biggest gripe with this otherwise wonderful
> language. I really don't understand why nothing is done about it.
Plenty has been done about it. Just not by ANSI.
vedm wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>
>>Andr� Thieme <······························@justmail.de> writes:
>>
>
>
> [..]
>
>
>>ANSI Common Lisp doesn't acknowledge that threads, interrupts,
>>or anything like that exists, of course.
>
>
> I started using Lisp only recently and the fact that the standard omits
> such essential features is my biggest gripe with this otherwise wonderful
> language. I really don't understand why nothing is done about it.
>
The fact that such things are not in the standard, does not mean they
are not available in implementation X (usually with pretty portable
interfaces).
This is a consequence of having one language standard and 8 (or 9: I
lost count) pretty much conforming implementations, as opposed to
languages where you have one implementation which is the standard.
Cheers
--
Marco
>>>>> "Christopher" == Christopher C Stacy <······@news.dtpq.com> writes:
Christopher> Andr� Thieme <······························@justmail.de> writes:
>> What does this mean? "Not interrupt-safe"?
Christopher> You would expect that a Lisp function could be registered as an
Christopher> interrupt handler. This works by having the Lisp implementation
Christopher> provide the real interrupt handler, which in turn properly arranges
Christopher> the system for the registered Lisp function to be called, work normally,
Christopher> and for it to return. (That's what Lisp did in the early 1970s.)
Christopher> I took Raymond's comment to mean that CMUCL is _not_ such a Lisp
Christopher> implementation. There is an interface directly to the underlying
Christopher> Unix signal calls, and you can get a Lisp function invoked.
Christopher> But things have not been properly arranged to ensure that the
Christopher> stack and other internal data structures and functions are
Christopher> preserved correctly. Maybe you'll get lucky, but maybe the entire
Christopher> Lisp implemenation will go ka-blooey. If that's truly what was meant,
Christopher> that would be a pretty sad state of affairs.
CMUCL does allow you to install Lisp functions as an interrupt
handler.
I don't really understand the situation completely, but I think if an
interrupt happens in unusual places, bad things might happen. Perhaps
like if you're modifying a hash table and you get an interrupt and the
handler also wants to modify the same hash table. Your hash table
could be destroyed.
Gerd Moellman implemented a statistical profiler for CMUCL sometime
back. It works fairly well on x86 (less so on sparc), but once in a
while you get random segfaults and such in code that was working.
These kinds of bugs are hard to find.
Ray
vedm wrote:
> Is there a timer function in cmucl? I want to call a function
> periodically and in a separate thread. Looking at the "mp" package I do
> not see something like "make-timer"..
My simple solution:
(defun make-timer (fun period)
(mp:make-process #'(lambda ()
(loop
(funcall fun)
(sleep period))) :name "timer"))
test:
(defun my-func () (print 'OK))
(make-timer 'my-func 1)
Seems to works.
--
Pozdrawiam,
Rafał Strzaliński (nabla)
nabla <···············@nospam.gmail.com> writes:
> vedm wrote:
> > Is there a timer function in cmucl? I want to call a function
> > periodically and in a separate thread. Looking at the "mp" package I do
> > not see something like "make-timer"..
>
> My simple solution:
>
> (defun make-timer (fun period)
> (mp:make-process #'(lambda ()
> (loop
> (funcall fun)
> (sleep period))) :name "timer"))
>
> test:
>
> (defun my-func () (print 'OK))
> (make-timer 'my-func 1)
Thanks, I guess this will do for my purposes, or at least I will try.
--
vedm
vedm <··@nospam.com> wrote:
+---------------
| nabla <···············@nospam.gmail.com> writes:
| > vedm wrote:
| > > Is there a timer function in cmucl? I want to call a function
| > > periodically and in a separate thread. Looking at the "mp"
| > > package I do not see something like "make-timer"..
| >
| > My simple solution:
| > (defun make-timer (fun period)
| > (mp:make-process #'(lambda ()
| > (loop
| > (funcall fun)
| > (sleep period))) :name "timer"))
...
| Thanks, I guess this will do for my purposes, or at least I will try.
+---------------
Note that the SLEEP here is implemented internally within CMUCL
with a synchonous "select()" call whose timer arg is the minimum
of all current SLEEPers[1], and *not* using a SIGALRM interrupt handler,
so it should be safe from the concerns that others have been noting
about interrupt handlers.
-Rob
[1] Actually, the minimum of all sleeps and the value represented by
the pair of globals CL::*MAX-EVENT-TO-SEC* & CL::*MAX-EVENT-TO-USEC*,
whichever is smaller. The default values are 1 & 0 respectively
[one second], which can make scheduling sluggish in some cases,
in which case you might want to try this:
(setf cl::*max-event-to-usec* 10000 ; frequent testing during sleeps
cl::*max-event-to-sec* 0)
Alternatively, if you call MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
during your program's startup [which can be a bit tricky to do
if you use a detached script to start it -- the call must be
the *very* last thing in the startup script], you can leave the
MAX-EVENT-xxx vars alone and things seem to work just fine.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607