One bug fix:

any eagain(any ex __attribute__((unused))) {
   return boxCnt(EAGAIN);

should be

any eagain(any ex __attribute__((unused))) {
   return boxCnt(-EAGAIN);

as (eagain) should be a negative value.  Negative values returned by
rdx and wrx mean errno. And, EAGAIN value returned by rdx or wrx
should not end the the callback task.

            (unless (or (gt0 N) (= N 'EAGAIN))
               (setq End (cons rd N)))))

It "worked" for me yesterday because I did not test the "negative"
example which would verify that it really is not blocking.

>    abu:~/pico ./p dbg.l
>    : (connect "localhost" 4444)
>    -> 3
>    : (out 3 (wr 1 2 3 254 255))
>    -> 255

I used (out 3 (prinl "hi")) yesterday (or similar), and then I could
read the data back (in S (line T)).  I was quite surpriced how much
data I could write in the socket without reading out of it and still
didn't get any error.  I still probably didn't send enough data to
fill the buffers.

> The difficult thing might be the negative test. Perhaps send a *lot*
> of data, and do some "ifconfig xxx down" in between?

Probably.  I could not find much on Google, maybe but haven't looked into it yet.  It
might be enough to put a print statement for eagain case, try some
heavy load testing, maybe try to disrupt it somehow as you suggest (or
introduce back the above bug) and see what happens.  So, unless
somebody finds it blocks I would consider it non-blocking for now;-)

> There is already a closure for 'Sock'

I see.

> should also work. But you could put your buffer there:
>    (task @
>       Buffer (need 5)
>       (callback @ Buffer) )


For Konrad's chat application, the buffer should be shared by all
callbacks as it is now.  It might be handy to have it local for other
applications.  Also, now the buffer is fixed sized which is one way of
implementing it and has its pros and cons.

There could be versions of rdx wrx which would use 'fifo' instead and
this would provide "unbounded" buffer.  The buffer management would be
simpler in this case but I am not sure whether it is a good idea
having no constraints on i/o buffers.

>> also be useful if it would be possible optionally switch on -g without
>> having to modify the gcc.l file.
> I would use 'patch' in such a case:
>    (patch gcc
>       '(apply @A "-o" @Z)
>       (append '(apply) @A '("-g" "-o") @Z) )

Nice trick:-)



Reply via email to