Porting guile-websocket to fibers about fibers

[cwebber]

Note that when I ported websockets to 8sync I'm pretty sure I fixed this very problem also. Remember that guile-websockets wasn't tested originally against an async environment.

I'll be working on getting the fixes I did to guile-websockets when I bundled it with 8sync upstream soon.

[amirouche]

Any help on this?

[jellelicht]

@amirouche: I checked out your repo, and updated guile to 2.2;
After some very crude (display ...) based debugging, it seems that your code as-is blocks in:

  (define (read-frame-maybe)
    (and (not (port-eof? client-socket))
         (read-frame client-socket)))

Some further research let me to:

 -- Scheme Procedure: port-eof? input-port
     Equivalent to ‘(eof-object? (lookahead-u8 INPUT-PORT))’.

 -- Scheme Procedure: get-u8 port
 -- C Function: scm_get_u8 (port)
     Return an octet read from PORT, an input port, blocking as
     necessary, or the end-of-file object.

 -- Scheme Procedure: lookahead-u8 port
 -- C Function: scm_lookahead_u8 (port)
     Like ‘get-u8’ but does not update PORT’s position to point past the
     octet.

So I guess you are calling this on a port that is waiting to be filled (whereas the other side of this story is probably also waiting on a reply first).

p.s. I do not see the 7-times-refresh behaviour you mention.

[amirouche]

@cwebber let me know when it's pushed upstream please.

[amirouche]

@cwebber any news? Is it possible to use 8sync to create a web application using websockets? tia

[cwebber]

@amirouche Yes, the MUD you see on the video on https://www.gnu.org/software/8sync/ is using websockets + 8sync, and so is https://test.activitypub.rocks/

However 8sync is not really the right home for it. I spoke to David Thompson recently and suggested we fold websockets support into guile-webutils and he supported that idea. Once we move support there you could use websockets with fibers or 8sync (which is going to use Fibers in the next release anyhow) or whatever event loop you want.