Helmut Eller | 11 May 2012 11:44

Daily ChangeLog diff

Index: slime/ChangeLog
diff -u slime/ChangeLog:1.2336 slime/ChangeLog:1.2338
--- slime/ChangeLog:1.2336	Sun May  6 23:10:50 2012
+++ slime/ChangeLog	Thu May 10 23:52:18 2012
 <at>  <at>  -1,3 +1,14  <at>  <at> 
+2012-05-11  Helmut Eller  <heller <at> common-lisp.net>
+
+	* swank-sbcl.lisp (stream-force-output): Don't use
+	with-deadline. Grab the world-lock instead.
+	(condition-timed-wait): Use the :timeout argument for real.
+
+2012-05-11  Helmut Eller  <heller <at> common-lisp.net>
+
+	* swank-backend.lisp (call-with-io-timeout): Not used. Deleted.
+	* swank-sbcl.lisp (call-with-io-timeout): Deleted.
+
 2012-05-07  Helmut Eller  <heller <at> common-lisp.net>

 	Ignore linebreaks for the macroexpand test.

Cyrus Harmon | 11 May 2012 18:37

Re: Daily ChangeLog diff


These changes break my usual SLIME stress test (shown below). Reverting back to
6df43a1ab6d434ba5f1d7bd39e79779e12524b73 fixes the problem.

Cyrus

CL-USER> (asdf:test-system 'flexi-streams)
STYLE-WARNING: Implicitly creating new generic function READ-SEQUENCE*.
STYLE-WARNING: Implicitly creating new generic function CHECK-IF-OPEN.
STYLE-WARNING: Implicitly creating new generic function TRANSFORM-OCTET.
STYLE-WARNING:
   Implicitly creating new generic function MAKE-IN-MEMORY-INPUT-STREAM.
STYLE-WARNING:
   Implicitly creating new generic function GET-OUTPUT-STREAM-SEQUENCE.
STYLE-WARNING:
   Implicitly creating new generic function OUTPUT-STREAM-SEQUENCE-LENGTH.
STYLE-WARNING:
   Generic function CLOSE clobbers an earlier FTYPE proclamation
   (FUNCTION (STREAM &KEY (:ABORT T)) (VALUES (MEMBER T) &OPTIONAL)) for
   the same name with (FUNCTION (T &KEY (:ABORT T)) *).
STYLE-WARNING: Implicitly creating new generic function READ-BYTE*.
STYLE-WARNING: Implicitly creating new generic function UNREAD-BYTE.
STYLE-WARNING: Implicitly creating new generic function PEEK-BYTE.
STYLE-WARNING: Implicitly creating new generic function RESET-INPUT-STATE.
STYLE-WARNING: Implicitly creating new generic function RESET-OUTPUT-STATE.
Test suite: "Reading/writing files"
.Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA (SB-DEBUG::FRAME) :IN BACKTRACE) {1008F0340B}>
:START 0 :COUNT 4611686018427387903)
1: (BACKTRACE 4611686018427387903 #<TWO-WAY-STREAM :INPUT-STREAM
(Continue reading)

Helmut Eller | 11 May 2012 20:09

Re: Daily ChangeLog diff

* Cyrus Harmon [2012-05-11 16:37] writes:

> These changes break my usual SLIME stress test (shown
> below). Reverting back to 6df43a1ab6d434ba5f1d7bd39e79779e12524b73
> fixes the problem.

Should be fixed in HEAD.

Helmut

Nikodemus Siivola | 11 May 2012 18:45
Gravatar

Re: Daily ChangeLog diff

On 11 May 2012 12:44, Helmut Eller <heller <at> common-lisp.net> wrote:

> +       * swank-sbcl.lisp (stream-force-output): Don't use
> +       with-deadline. Grab the world-lock instead.

What's the logic behind this change? This will break.

Cheers,

 -- nikodemus

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel
Helmut Eller | 11 May 2012 20:09

Re: Daily ChangeLog diff

* Nikodemus Siivola [2012-05-11 16:45] writes:

> On 11 May 2012 12:44, Helmut Eller <heller <at> common-lisp.net> wrote:
>
>> +       * swank-sbcl.lisp (stream-force-output): Don't use
>> +       with-deadline. Grab the world-lock instead.
>
> What's the logic behind this change?

The purpose is to get rid of WITH-DEADLINE.

> This will break.

We will see.

Helmut

Nikodemus Siivola | 13 May 2012 10:39
Gravatar

Re: Daily ChangeLog diff

On 11 May 2012 21:09, Helmut Eller <heller <at> common-lisp.net> wrote:

>> What's the logic behind this change?
>
> The purpose is to get rid of WITH-DEADLINE.

This seems overly pedantic to me.

You may not like the API, but unlike WITH-WORLD-LOCK it is actually a
supported API It's one of the three constructs that should almost
never be used along with WITHOUT-GCING and WITH-TIMEOUT.

Unless it made the sources too ugly, I would not hesitate to rename it
%%WITH-WORLD-LOCK-INTERNAL-DONT-USE-AND-AVOID-EVEN-INSIDE-SBCL...

Cheers,

 -- Nikodemus

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel
Helmut Eller | 13 May 2012 18:58

Re: Daily ChangeLog diff

* Nikodemus Siivola [2012-05-13 08:39] writes:

> On 11 May 2012 21:09, Helmut Eller <heller <at> common-lisp.net> wrote:
>
>>> What's the logic behind this change?
>>
>> The purpose is to get rid of WITH-DEADLINE.
>
> This seems overly pedantic to me.
>
> You may not like the API, 

Henceforth, I shall use all the APIs that I don't like, sir.

> but unlike WITH-WORLD-LOCK it is actually a
> supported API

As well "supported" as the wonderful and thread-safe method dispatching.
How long is the non-problem with the dispatch caches known?  Months or
years?  When, if ever, will it be fixed?  Ah I know: wishing for
thread-safe dispatch caches is overly pedantic.  Certainly it's more
honorable to defend WITH-DEADLINE than to fix dispatch caches.

> It's one of the three constructs that should almost
> never be used along with WITHOUT-GCING and WITH-TIMEOUT.

What should not be used: WITH-DEADLINE or WITH-WORLD-LOCK?  Obviously
WITH-WORLD-LOCK is one of the three bad guys.  Unless we can't count,
WITH-DEADLINE should be used gratuitously, or not.

(Continue reading)

Nikodemus Siivola | 13 May 2012 21:58
Gravatar

Re: Daily ChangeLog diff

On 13 May 2012 19:58, Helmut Eller <heller <at> common-lisp.net> wrote:

> What should not be used: WITH-DEADLINE or WITH-WORLD-LOCK?  Obviously

WITH-DEADLINE should be used, IMO. I don't quite follow what you
consider to be the problem with it.

The reason grabbing WITH-WORLD-LOCK is bad is because doing that
creates new places where things can deadlock.

When we finally get rid of the world lock around (or hack CLOS
dispatch to use evaluated functions when the compiler is taken), every
single place where world lock is grabbed is still a potential
deadlock: world lock is bad (like any other huge lock) not just
because it kilsl parallelism, but because reasoning about lock
ordering becomes essentially impossible. If a system has one lock lock
big enough that arbitrary code can run inside means that's bad but ...
survivable. If there are two or more such locks, then those locks
can't really have a proper ordering between them, and you get
deadlocks.

The second reason WITH-WORLD-LOCK is bad is that I'm trying get rid of
it by breaking it up into smaller locks. So swank-sbcl.lisp will need
more #+magic -- not terrible, but not ideal either.

Cheers,

 -- Nikodemus

_______________________________________________
(Continue reading)

Helmut Eller | 13 May 2012 23:06

Re: Daily ChangeLog diff

* Nikodemus Siivola [2012-05-13 19:58] writes:

> On 13 May 2012 19:58, Helmut Eller <heller <at> common-lisp.net> wrote:
>
>> What should not be used: WITH-DEADLINE or WITH-WORLD-LOCK?  Obviously
>
> WITH-DEADLINE should be used, IMO. I don't quite follow what you
> consider to be the problem with it.

If a timeout occurs in the middle of a non-atomic code sequence, some
heap object can be in a non-consistent state.  E.g. the buffer contents
gets sent to Emacs before resetting the buffer index; if the timeout
occurs before updating the index, some output can be sent twice.

Helmut


Gmane