freenode/#mezzano - IRC Chatlog
Search
12:44:47
sts-q
To move a window programmatically i say (mezzano.gui.compositor:move-window (window viewer) new-xpos new-ypos)
12:58:32
froggey
(mezzano.gui.widgets:resize-frame window-frame the-surface-returned-by-make-surface)
12:59:17
froggey
you should do that before the call to resize-window so the frame is immediately visible once the compositor switches surfaces
13:00:34
ebrasca
froggey: Have you merged my changes from slime into your branch? ( They are upstream )
17:48:02
ebrasca
froggey: I don't like recursive locks. Can you make some automatic fixing function?
18:20:39
froggey
close-tcp-connection is trying to acquire a connection lock that is already held. you can look through the backtrace for calls to call-with-mutex to see what other function are holding locks
18:21:28
ebrasca
Does mezzano.supervisor:condition-wait-for return some not nil value when it worked?
18:23:10
froggey
it returns a non-nil value if the predicate returns non-nil. it returns nil if the timeout expires
18:29:23
froggey
ok, there are two problems here: 1) the recursive locking error. 2) the unexpected timeout
18:39:02
froggey
close-tcp-connection wants to take the connection lock, but can't because it has already been taken by a function higher up on the call stack
18:39:45
froggey
you can identify the function that originally took the lock by looking for call-with-mutex in the backtrace
18:41:07
froggey
in your case it is %tcp4-receive, but the same bug is also present in tcp-connect as I just found out
18:42:42
froggey
(mezzano.network.tcp:tcp-stream-connect "10.10.10.10" 1) was enough for me to reproduce
18:43:04
froggey
close-tcp-connection doesn't need to do anything fancy with the lock, it does all its work with the lock held
18:43:24
froggey
it could be changed to not take the lock, and to require that it is called with the lock already held
18:43:57
froggey
it is only ever called from tcp-connect and the close method, so that's a viable solution
18:46:07
froggey
this kind of fix won't work everywhere, and it's not something we want to do for public interfaces. we don't want arbitrary code having to take internal locks
19:01:03
froggey
yeah, simpler to just change close-tcp-connection so that it must be called with the connection lock already held
19:04:26
froggey
like I said, just change close-tcp-connection so it is the caller's responsibility to take the lock
19:04:57
froggey
tcp-connect would be correct with this change and the close method would have to modified to take the lock around the call
19:10:05
froggey
changing close-tcp-connection to put locking responsibility on the caller on the other hand is fine and is what I would do