Any way to disable the "Alarm clock"?

I've got a script that takes a bit of time to run and
it seems to generate an Alarm clock message and abort
before its done.. Is there a way to either override the
duration or shut it off altogether?

Thx!

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, May 15, 2010 at 03:23, Rick Flower <[hidden email]> wrote:
> I've got a script that takes a bit of time to run and
> it seems to generate an Alarm clock message and abort
> before its done.. Is there a way to either override the
> duration or shut it off altogether?

It's a bug in GNU Smalltalk, possibly triggered by a bug in your
script (or maybe not).  The "Alarm clock" is used to implement the
Delay class.

Can you attach the script or a "strace" of its execution?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, 16 May 2010 08:57:02 +0200, Paolo Bonzini <[hidden email]> wrote:
Yes, eventually.. The script traverses the current filesystem and for
each real file executes a commmand using the 'system' call and
builds a stream pipe to analyze the results.  It can take quite some
time for this to occur depending on the number of files to analyze.
In this case I'm using it to build a tree of problem report
objects for each file for a software release I'm working on (in C++)
for my day job.  Seemed much easier to do in GST than in Perl
besides the fact that I'd learn stuff and keep my ST brain fresh!

I'll see about adding some strace output if this continues to
occur..

P.S.  Is there a good way to do something akin to C's sscanf()
stuff in Smalltalk.  The stream classes don't (at first glance)
appear to make breaking apart lines easy/efficient... TIA for
any pointers you can recommend!

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Yes, eventually.. The script traverses the current filesystem and for
> each real file executes a commmand using the 'system' call and
> builds a stream pipe to analyze the results.  It can take quite some
> time for this to occur depending on the number of files to analyze.

Maybe it's a race that occurs after forking... I need to read some
manpages or make an equivalent minimal C testcase.

> P.S.  Is there a good way to do something akin to C's sscanf()
> stuff in Smalltalk.  The stream classes don't (at first glance)
> appear to make breaking apart lines easy/efficient...

I suppose you can use regexes on each line.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, 16 May 2010 08:57:02 +0200, Paolo Bonzini <[hidden email]> wrote:
Paolo,

Is the Alarm also possibly working as a means to ensuring a
script does not 'run-away' and get stuck?  I was running my
almost done script yesterday (this time using vanilla gst 3.2)
and it hit the alarm after running for several minutes
doing text analysis with pipes,etc..  Unfortunately the code
is very tied to our environment so it can't be run elsewhere
but I'd be happy to debug the issue if you could point me in
the right direction..

Thx!

-- Rick

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/26/2010 07:13 PM, Rick Flower wrote:
No, the alarm is just a SIGALRM that is not properly trapped.  It should
never happen.

Please include a "strace -e sigaction" or something like that.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 26 May 2010 20:51:10 +0200, Paolo Bonzini <[hidden email]> wrote:
> No, the alarm is just a SIGALRM that is not properly trapped.  It should

> never happen.
>
> Please include a "strace -e sigaction" or something like that.

Here you go (using truss on Solaris):

sigaction(SIGALRM, 0xFFBEE9B8, 0xFFBEEA68)      = 0
sigprocmask(SIG_BLOCK, 0xFFBEEA58, 0xFFBEEA48)  = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0x00000000)  = 0
    Received signal #14, SIGALRM, in sigsuspend() [caught]
sigsuspend(0xFFBEEA38)                          Err#4 EINTR
setcontext(0xFFBEE720)
sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEEA58, 0x00000000) = 0
setitimer(ITIMER_REAL, 0xFFBEEAA8, 0x00000000)  = 0
sigprocmask(SIG_BLOCK, 0xFFBEEBE8, 0xFF35414C)  = 0
sigprocmask(SIG_SETMASK, 0xFF35414C, 0x00000000) = 0
alarm(0)                                        = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0xFFBEEAA8)  = 0
sigaction(SIGALRM, 0xFFBEE9B8, 0xFFBEEA68)      = 0
sigprocmask(SIG_BLOCK, 0xFFBEEA58, 0xFFBEEA48)  = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0x00000000)  = 0
    Received signal #14, SIGALRM, in sigsuspend() [caught]
sigsuspend(0xFFBEEA38)                          Err#4 EINTR
setcontext(0xFFBEE720)
sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEEA58, 0x00000000) = 0
setitimer(ITIMER_REAL, 0xFFBEEAA8, 0x00000000)  = 0
sigprocmask(SIG_BLOCK, 0xFFBEEBE8, 0xFF35414C)  = 0
sigprocmask(SIG_SETMASK, 0xFF35414C, 0x00000000) = 0
alarm(0)                                        = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0xFFBEEAA8)  = 0
sigaction(SIGALRM, 0xFFBEE9B8, 0xFFBEEA68)      = 0
sigprocmask(SIG_BLOCK, 0xFFBEEA58, 0xFFBEEA48)  = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0x00000000)  = 0
    Received signal #14, SIGALRM, in sigsuspend() [caught]
sigsuspend(0xFFBEEA38)                          Err#4 EINTR
setcontext(0xFFBEE720)
sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEEA58, 0x00000000) = 0
setitimer(ITIMER_REAL, 0xFFBEEAA8, 0x00000000)  = 0
sigprocmask(SIG_BLOCK, 0xFFBEEBE8, 0xFF35414C)  = 0
sigprocmask(SIG_SETMASK, 0xFF35414C, 0x00000000) = 0
alarm(0)                                        = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0xFFBEEAA8)  = 0
sigaction(SIGALRM, 0xFFBEE9B8, 0xFFBEEA68)      = 0
sigprocmask(SIG_BLOCK, 0xFFBEEA58, 0xFFBEEA48)  = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0x00000000)  = 0
    Received signal #14, SIGALRM, in sigsuspend() [caught]
sigsuspend(0xFFBEEA38)                          Err#4 EINTR
setcontext(0xFFBEE720)
sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEEA58, 0x00000000) = 0
setitimer(ITIMER_REAL, 0xFFBEEAA8, 0x00000000)  = 0
sigprocmask(SIG_BLOCK, 0xFFBEEBE8, 0xFF35414C)  = 0
sigprocmask(SIG_SETMASK, 0xFF35414C, 0x00000000) = 0
alarm(0)                                        = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0xFFBEEAA8)  = 0
sigaction(SIGALRM, 0xFFBEE9B8, 0xFFBEEA68)      = 0
sigprocmask(SIG_BLOCK, 0xFFBEEA58, 0xFFBEEA48)  = 0
setitimer(ITIMER_REAL, 0xFFBEEAB8, 0x00000000)  = 0
sigsuspend(0xFFBEEA38)                          Err#4 EINTR
waitid(P_ALL, 0, 0xFFBEE578, WEXITED|WTRAPPED|WNOHANG) = 0
waitid(P_ALL, 0, 0xFFBEE578, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD
getpid()                                        = 1892 [1891]
kill(1892, SIGPOLL)                             = 0
sigaction(SIGCLD, 0xFFBEE538, 0xFFBEE5B8)       = 0
setcontext(0xFFBEE720)
sigaction(SIGPOLL, 0xFFBEE540, 0xFFBEE5C0)      = 0
setcontext(0xFFBEE720)
sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEEA58, 0x00000000) = 0
    Received signal #14, SIGALRM [default]
        *** process killed ***

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/26/2010 09:23 PM, Rick Flower wrote:
> On Wed, 26 May 2010 20:51:10 +0200, Paolo Bonzini<[hidden email]>  wrote:
>> No, the alarm is just a SIGALRM that is not properly trapped.  It should
>
>> never happen.
>>
>> Please include a "strace -e sigaction" or something like that.
>
> Here you go (using truss on Solaris):

Thanks, very helpful.  I think I see what's going on.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 26 May 2010 21:46:06 +0200, Paolo Bonzini <[hidden email]> wrote:
> On 05/26/2010 09:23 PM, Rick Flower wrote:
>> On Wed, 26 May 2010 20:51:10 +0200, Paolo Bonzini<[hidden email]>
>> wrote:
>>> No, the alarm is just a SIGALRM that is not properly trapped.  It
should
>>
>>> never happen.
>>>
>>> Please include a "strace -e sigaction" or something like that.
>>
>> Here you go (using truss on Solaris):
>
> Thanks, very helpful.  I think I see what's going on.

Ok.. Let me know if you want to try a fix.. Thx!

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/26/2010 09:23 PM, Rick Flower wrote:
> sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0

This is not coming from GNU Smalltalk.  I always have a non-NULL third
argument.  Can you put a breakpoint on sigaction, conditional on the
third argument being nil, and see if you can get a backtrace?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, 27 May 2010 07:30:48 +0200, Paolo Bonzini <[hidden email]> wrote:
> On 05/26/2010 09:23 PM, Rick Flower wrote:
>> sigaction(SIGALRM, 0xFFBEE9B8, 0x00000000)      = 0
>
> This is not coming from GNU Smalltalk.  I always have a non-NULL third
> argument.  Can you put a breakpoint on sigaction, conditional on the
> third argument being nil, and see if you can get a backtrace?

That seems to be about right -- I actually put an assert in the
offending code within _gst_set_signal_handler() to ensure the
o_act argument is always non-null.. I rebuild and reran the test code
and it still fails but not on the assert -- which never triggered.

I'll look some more.. to see what is causing this.. It's hard to
tell without a stackdump..

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/28/2010 01:32 AM, Rick Flower wrote:

> I'll look some more.. to see what is causing this.. It's hard to
> tell without a stackdump..

Is gdb available for Solaris? or can dbx break in sigaction and support
conditional breakpoints? Or what about DTrace? It should be fairly easy
to see who is calling sigaction.

regards
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, 27 May 2010 10:32:21 -0700, Rick Flower <[hidden email]>
wrote:

> I'll look some more.. to see what is causing this.. It's hard to
> tell without a stackdump..

Ok.. More info w/ truss.. This time showing calls into libgst.so
just prior to the alarm that kills it :

4685/1:                           <- libgst:execute_primitive_operation()
= 0
4685/1:                         <- libgst:_gst_send_message_internal() = 0
4685/1:                         ->
libgst:_gst_send_message_internal(0xfac02b90, 0x0, 0xfac462a0, 0xfac03360)
4685/1:                         <- libgst:_gst_send_message_internal() =
0xfac35c08
4685/1:                         -> libgst:unwind_context(0x1, 0xfac2c160,
0xfac462a0, 0xfac2c160)
4685/1:                         <- libgst:unwind_context() = 0xfac2c160
4685/1:                         -> libgst:unwind_context(0x3, 0xfac2c160,
0xfac462a0, 0xfac2c160)
4685/1:                         <- libgst:unwind_context() = 0xfac35c08
4685/1:                         ->
libgst:_gst_send_message_internal(0xfac35b80, 0x1, 0xfac02820, 0xfac03458)
4685/1:                           ->
libgst:execute_primitive_operation(0x86, 0x1, 0x0, 0x0)
4685/1:                             -> libgst:VMpr_Processor_pause(0x0,
0x1, 0x0, 0x0)
4685/1:                               -> libgst:_gst_usleep(0x4e20, 0x0,
0x0, 0x0)
4685/1:         alarm(0)                                        = 0
4685/1:         setitimer(ITIMER_REAL, 0xFFBEEA90, 0xFFBEEA80)  = 0
4685/1:         sigaction(SIGALRM, 0xFFBEE990, 0xFFBEEA40)      = 0
4685/1:         sigprocmask(SIG_BLOCK, 0xFFBEEA30, 0xFFBEEA20)  = 0
4685/1:         setitimer(ITIMER_REAL, 0xFFBEEA90, 0x00000000)  = 0
4685/1:         sigsuspend(0xFFBEEA10)                          Err#4
EINTR
4685/1:                                 ->
libgst:file_polling_handler(0x16, 0x0, 0xffbee6f8, 0xff23c008)
4685/1:                                   ->
libgst:_gst_disable_interrupts(0x1, 0x0, 0x0, 0x0)
4685/1:                                   <-
libgst:_gst_disable_interrupts() = 1
4685/1:                                   ->
libgst:_gst_async_call(0xff2cf020, 0x0, 0x0, 0x0)
4685/1:                                   <- libgst:_gst_async_call() =
0xff2cf020
4685/1:                                   ->
libgst:_gst_enable_interrupts(0x1, 0x0, 0x0, 0x0)
4685/1:                                   <-
libgst:_gst_enable_interrupts() = 1
4685/1:                                   ->
libgst:_gst_set_signal_handler(0x16, 0xff2cfa1c, 0x0, 0x0)
4685/1:         sigaction(SIGPOLL, 0xFFBEE518, 0xFFBEE598)      = 0
4685/1:                                   <-
libgst:_gst_set_signal_handler() = 0xff2cfa1c
4685/1:                                 -> libgst:_gst_wakeup(0x16, 0x0,
0xffbee6f8, 0xff23c008)
4685/1:                                   -> libgst:glthread_in_use(0x0,
0x0, 0x0, 0x0)
4685/1:                                   <- libgst:glthread_in_use() = 0
4685/1:                                 <- libgst:file_polling_handler() =
22
4685/1:         setcontext(0xFFBEE6F8)
4685/1:         sigaction(SIGALRM, 0xFFBEE990, 0x00000000)      = 0
4685/1:         sigprocmask(SIG_UNBLOCK, 0xFFBEEA30, 0x00000000) = 0
4685/1:             Received signal #14, SIGALRM [default]
4685/1:                 *** process killed ***

I haven't had the time yet to try to digest what this means..
I'll look into it after lunch..

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, 28 May 2010 01:55:25 +0800, Holger Hans Peter Freyther
<[hidden email]> wrote:
> On 05/28/2010 01:32 AM, Rick Flower wrote:
>
>> I'll look some more.. to see what is causing this.. It's hard to
>> tell without a stackdump..
>
> Is gdb available for Solaris? or can dbx break in sigaction and support
> conditional breakpoints? Or what about DTrace? It should be fairly easy
> to see who is calling sigaction.

I've got gdb (not dbx) and no you can not break on system
functions like sigaction.. I set a breakpoint in the only
place in the code that calls sigaction and it triggers
but I see no issue with what is being done there.

I suppose it might be possible to override and specify
a local version of sigaction that does nothing but
monitor the arguments but I'm not sure that can be done
or what side effects it might cause because the 'real'
sigaction would not be called at all..

-- Rick

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, 27 May 2010 12:58:30 -0700, Rick Flower <[hidden email]>
wrote:
> On Fri, 28 May 2010 01:55:25 +0800, Holger Hans Peter Freyther
> <[hidden email]> wrote:
>> On 05/28/2010 01:32 AM, Rick Flower wrote:
>>
>>> I'll look some more.. to see what is causing this.. It's hard to
>>> tell without a stackdump..

Ok.. I think I have an idea of what's going on and why sigaction
is different with the 3rd argument.. Here's a snippet that seems to
shed some light on why the sigaction's 3rd argument is zero :

4685/1:                      -> libgst:_gst_usleep(0x4e20, 0x0, 0x0, 0x0)
4685/1: alarm(0) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0xFFBEEA80) = 0
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0xFFBEEA40) = 0
4685/1: sigprocmask(SIG_BLOCK, 0xFFBEEA30, 0xFFBEEA20) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0x00000000) = 0
4685/1:    Received signal #14, SIGALRM, in sigsuspend() [caught]
4685/1: sigsuspend(0xFFBEEA10) Err#4 EINTR
4685/1: setcontext(0xFFBEE6F8)
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0x00000000) = 0
4685/1: sigprocmask(SIG_UNBLOCK, 0xFFBEEA30, 0x00000000) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA80, 0x00000000) = 0
4685/1:                      <- libgst:_gst_usleep() = 0

This seems to imply that the GST kernel calls _gst_usleep(20000)
and that code in turn is calling usleep (Solaris 8 defines both
HAVE_USLEEP and HAVE_NANOSLEEP) which in turn is doing all of the
signal crap you see above starting with the alarm(0), sigaction,etc.
You can see the return from the _gst_usleep() function at the
bottom.. I'm going to switch over to using nanosleep with
will behave differently and see if that has any effect as the
manpage for it indicates that it does not mess with any signal
handling,etc.

By the way.. For reference, the truss line I'm using to gather
this up (in the off chance it may be useful for someone else)
is :

% truss -lf -s SIGALRM -u libgst,libsigsegv:: myCoolGSTScript >&foo.log

I'll keep you posted..

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, 27 May 2010 16:19:28 -0700, Rick Flower <[hidden email]>
wrote:

In looking closer at the dump I provided earlier and
comparing it to equivalent processing earlier in the
202Mb log file, I see something at the end I don't
see elsewhere :

4685/1:     -> libgst:_gst_send_message_internal(0xfac35b80, 0x1,
0xfac02820, 0xfac03458)
4685/1:       -> libgst:execute_primitive_operation(0x86, 0x1, 0x0, 0x0)
4685/1:         -> libgst:VMpr_Processor_pause(0x0, 0x1, 0x0, 0x0)
4685/1:           -> libgst:_gst_usleep(0x4e20, 0x0, 0x0, 0x0)
4685/1: alarm(0) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0xFFBEEA80) = 0
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0xFFBEEA40) = 0
4685/1: sigprocmask(SIG_BLOCK, 0xFFBEEA30, 0xFFBEEA20) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0x00000000) = 0
4685/1: sigsuspend(0xFFBEEA10) Err#4 EINTR
4685/1:              -> libgst:file_polling_handler(0x16, 0x0,
0xffbee6f8, 0xff23c008)
4685/1:                -> libgst:_gst_disable_interrupts(0x1, 0x0, 0x0,
0x0)
4685/1:                <- libgst:_gst_disable_interrupts() = 1
4685/1:                -> libgst:_gst_async_call(0xff2cf020, 0x0, 0x0,
0x0)
4685/1:                <- libgst:_gst_async_call() = 0xff2cf020
4685/1:                -> libgst:_gst_enable_interrupts(0x1, 0x0, 0x0,
0x0)
4685/1:                <- libgst:_gst_enable_interrupts() = 1
4685/1:                -> libgst:_gst_set_signal_handler(0x16,
0xff2cfa1c, 0x0, 0x0)
4685/1: sigaction(SIGPOLL, 0xFFBEE518, 0xFFBEE598) = 0
4685/1:                <- libgst:_gst_set_signal_handler() = 0xff2cfa1c
4685/1:              -> libgst:_gst_wakeup(0x16, 0x0, 0xffbee6f8,
0xff23c008)
4685/1:                -> libgst:glthread_in_use(0x0, 0x0, 0x0, 0x0)
4685/1:                <- libgst:glthread_in_use() = 0
4685/1:              <- libgst:file_polling_handler() = 22
4685/1: setcontext(0xFFBEE6F8)
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0x00000000) = 0
4685/1: sigprocmask(SIG_UNBLOCK, 0xFFBEEA30, 0x00000000) = 0
4685/1:    Received signal #14, SIGALRM [default]
4685/1: *** process killed ***

Without knowing more about the GST kernel innards, it seems
like the VMpr_Processor_pause() is being interrupted by
file_polling_handler().. Right after the sigsuspend done as
part of _gst_usleep(), the processing is interrupted a new
sigaction(SIGPOLL) is called and then the setcontext() is called
on behalf of _gst_usleep().  I didn't see that anywhere else
and suspect that's a bad sequence of events.. Am I on the
right track?  I'm not completely sure how file_polling_handler()
is used (is it like an interrupt/signal handler or something
that can happen asynchronously?)

Hope this makes sense..
 

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Ok.. Solved!!

For Solaris 8 do NOT set #define HAVE_USLEEP 1..
Just use the other one -- HAVE_NANOSLEEP.  After rebuilding
with that config all is well and my very long winded script
runs to completion after about 5 minutes of solid chomping
on strings and pipe output.

This may be a generic Solaris issue -- haven't tried
Solaris 9 or 10..

I did check the manpages for Solaris 10 version of usleep
and it is probably OK -- this is what the Solaris 10 version
of usleep says about interactions with alarms & signals :

     The use of the usleep() function has no effect on the action
     or  blockage of any signal. In a multithreaded process, only
     the invoking thread is suspended from execution.

Below is the Solaris 8 equivalent :

     Interactions  between  usleep()  and  either   alarm(2)   or
     sleep(3C) are unspecified.

Now -- both versions of Solaris (8 & 10) have this to say
about using usleep():

  USAGE
     The usleep() function is included for its historical  usage.
     The nanosleep(3RT) function is preferred over this function.

It sounds to me like nobody on any version of Solaris 8,9,10 and
perhaps earlier versions should be using usleep but should use
nanosleep instead.. Can we make that the default for Solaris
systems?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> For Solaris 8 do NOT set #define HAVE_USLEEP 1..
> Just use the other one -- HAVE_NANOSLEEP.  After rebuilding
> with that config all is well and my very long winded script
> runs to completion after about 5 minutes of solid chomping
> on strings and pipe output.

I was about to ask you testing the same! Thanks!

> It sounds to me like nobody on any version of Solaris 8,9,10 and
> perhaps earlier versions should be using usleep but should use
> nanosleep instead.. Can we make that the default for Solaris
> systems?

Actually I'm going to do that for every system that supports nanosleep.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk