Re: [Chicken-users] readline blocks threads

[Shawn Rutledge]

On Wed, Mar 5, 2008 at 11:50 PM, Shawn Rutledge
<address@hidden> wrote:
>  So they're using Unix sockets.  It's already non-blocking, so F_SETFL
>  doesn't change the behavior.

But I guess I'm being stupid... readline (or the terminal? as you say)
is blocking, not dbus.  But it's good to know definitely what dbus is
using.

On Thu, Mar 6, 2008 at 12:53 AM, Elf <address@hidden> wrote:
>  the problem isnt nonblocking status.
>  the problem is that all the term settings get munged by readline - how else
>  could it interpret arrows, tabs, do paren bouncing, etc.

You mean the same settings that can be changed via stty?  I don't
understand what effect that has.  The usual kind of blocking that can
be turned on is that when you are sitting at a shell prompt,
keystrokes are not sent one-by-one, but rather it can wait until you
hit the enter key and send the whole command all at once; this is a
feature that can help with slow serial connections or packet networks.
 But I don't think that mode is in use much these days, and readline
would be turning off that feature, right? because it has to see each
keystroke in order to do all the tricks.  Or you think it's on the
output side, that the threads are blocked because output going from
csi to the screen does not pass through until it is flushed?  Then
maybe a thread which does no output would run fine, but one which
displays status messages would block?

>  i am working on a pure scheme readlineish lib to compensate with 
> approximately
>  the same feature set as what is presently there.  it should be done shortly.

OK I'll look forward to it.

So you don't have any philosophical problem with the idea that an egg
which does polling should automatically start a thread to do that?

>  however, instead of coding right now, im going through the almost 500 eggs
>  to make sure that the licence data is correct (ie, the licence tag and the

Doesn't sound like much fun.