Buggy redirect input in gemini #101

New Issue

sloum · 2019-11-27T06:07:38Z

sloum commented

2019-11-27 06:07:38 +00:00

I have found some buggy input behavior. I had experienced something like this in one of the file write modules and took it out because I couldnt find the source of the problem. This was working correctly before but seems to just freak out now.

To replicate:

Navigate to: gemini://gemini.circumlunar.space:1965/~sloum
You should get an ask if you would like to be redirected to: gemini://gemini.circumlunar.space:1965/~sloum/ (it wants to redirect to add the terminal slash)
Any key input seems to not work. I cannot for the life of me figure out why. If you press a key a few times eventually some keypress will register, but it is definitely not working correctly.

I would love some help on this as I have been baffled by this before and I'm still on spotty internet out in the woods. I'm not sure if this should hold up 2.0.0. or not.

Let me know your thoughts. If you are unable to replicate the issue it may be unique to my system for some reason.

I have found some buggy input behavior. I had experienced something like this in one of the file write modules and took it out because I couldnt find the source of the problem. This was working correctly before but seems to just freak out now. To replicate: 1. Navigate to: `gemini://gemini.circumlunar.space:1965/~sloum` 2. You should get an ask if you would like to be redirected to: `gemini://gemini.circumlunar.space:1965/~sloum/` (it wants to redirect to add the terminal slash) 3. Any key input seems to not work. I cannot for the life of me figure out why. If you press a key a few times eventually some keypress will register, but it is definitely not working correctly. I would **love** some help on this as I have been baffled by this before and I'm still on spotty internet out in the woods. I'm not sure if this should hold up 2.0.0. or not. Let me know your thoughts. If you are unable to replicate the issue it may be unique to my system for some reason.

asdf was assigned by sloum

2019-11-27 06:07:38 +00:00

sloum added the

bug

help wanted

gemini

labels 2019-11-27 06:07:59 +00:00

sloum commented

2019-11-27 06:11:28 +00:00

If you keep pressing y it will eventually register. Pressing anything else will also eventually register as no (do not follow the redirect).

If you keep pressing `y` it will eventually register. Pressing anything else will also eventually register as `no` (do not follow the redirect).

sloum commented

2019-11-27 06:15:43 +00:00

Ok. I think I have it figured out. We (I put them there, so me) are using a goroutine for c.Visit(u) on line 820 of the client. That means that we loop to another input loop for the regular input and are also asking for input from within the goroutine. Making Visit a blocking call should resolve the issue. I cant test it this second but will try to test it in the morning.

There are some other goroutines in the mix. If any of the possible calls down the goroutine paths would ask for input we probably cannot run them as goroutines without a channel. That is very doable but makes things a little more complicated. I think if the above fix works, then I would prefer just doing blocking calls for those calls for the time being. We can look into channels for a minor update later.

Feel free to skip looking into this one for the moment if you like.

Ok. I think I have it figured out. We (I put them there, so _me_) are using a goroutine for `c.Visit(u)` on line `820` of the client. That means that we loop to another input loop for the regular input and are also asking for input from within the goroutine. Making `Visit` a blocking call should resolve the issue. I cant test it this second but will try to test it in the morning. There are some other goroutines in the mix. If any of the possible calls down the goroutine paths would ask for input we probably cannot run them as goroutines without a channel. That is very doable but makes things a little more complicated. I think if the above fix works, then I would prefer just doing blocking calls for those calls for the time being. We can look into channels for a minor update later. Feel free to skip looking into this one for the moment if you like.

sloum self-assigned this 2019-11-27 06:18:10 +00:00

asdf referenced this issue

2019-11-27 08:34:55 +00:00

Change c.Visit(u) call to blocking, from goroutine #102

asdf commented

2019-11-27 09:12:37 +00:00

Funny, pressing y in rapid succession will allow you to continue. Rapidly, not slowly.

Just to clarify, making this a blocking call means removing the word from line 820 of client.go. This seems to fix the issue without a noticeable impact to performance.

I had a look and couldn't see anything else that might conflict. It's only cui.Getch() and cui.GetLine() that do a reader on stdin, and I don't think they are used in other goroutines.

Do you have an idea of how it might be fixed longer term? I'm having trouble understanding how it might work.

Funny, pressing `y` in rapid succession will allow you to continue. Rapidly, not slowly. Just to clarify, making this a blocking call means removing the word from line 820 of client.go. This seems to fix the issue without a noticeable impact to performance. I had a look and couldn't see anything else that might conflict. It's only cui.Getch() and cui.GetLine() that do a reader on stdin, and I don't think they are used in other goroutines. Do you have an idea of how it might be fixed longer term? I'm having trouble understanding how it might work.

sloum commented

2019-11-28 06:02:48 +00:00

The idea I had for a longer term fix is to make sure only one process tries to read from std-in at one time. To do so, a channel would need to be set up. Before any attempt to read from std-in the channel would need to be checked, if there was a token stating true or open or something or a 1, whatever, the the read can take place (reading the value should pop it off the channel so any subsequent attempts shouldn't see a value yet). When something gets the go-ahead token they do their read and then send a go-ahead token tot he channel when done. Anything wanting to read from std-in while there is nothing on the channel will loop and keep reading the channel until they get a go-ahead token (whatever that may be).

That is, at least in the abstract, how I think it could work. It, in my head, works similar to ownership in Rust, except in our case receiving the token from the channel transfers ownership of std-in.

The idea I had for a longer term fix is to make sure only one process tries to read from std-in at one time. To do so, a channel would need to be set up. Before any attempt to read from std-in the channel would need to be checked, if there was a token stating true or open or something or a 1, whatever, the the read can take place (reading the value should pop it off the channel so any subsequent attempts shouldn't see a value yet). When something gets the go-ahead token they do their read and then send a go-ahead token tot he channel when done. Anything wanting to read from std-in while there is nothing on the channel will loop and keep reading the channel until they get a go-ahead token (whatever that may be). That is, at least in the abstract, how I think it could work. It, in my head, works similar to ownership in Rust, except in our case receiving the token from the channel transfers ownership of std-in.

sloum commented

2019-11-28 06:04:00 +00:00

Closed, for now, by #102

sloum closed this issue

2019-11-28 06:04:05 +00:00

Sign in to join this conversation.