writelock_issue #45

Merged

modulatingforce merged 4 commits from issue-chat-say-id-write-lock into parent-botaction-to-child-fn

2024-03-24 23:44:25 -04:00

modulatingforce commented

2024-03-24 21:54:44 -04:00

Owner

After attempting to introduce functionality from #43 , noticing a complex issue with write() locks locking the bot at runtime

This branch and PR intends to find recommendations for write() locks so we avoid the current lock observed with the above

Relatively high priority - the parent PR has a lot of major changes, and this new PR is a show stopper

After attempting to introduce functionality from https://git.flake.sh/modulatingforce/forcebot_rs/pulls/43 , noticing a complex issue with `write()` locks locking the bot at runtime This branch and PR intends to find recommendations for `write()` locks so we avoid the current lock observed with the above --- Relatively high priority - the parent PR has a lot of major changes, and this new PR is a show stopper

modulatingforce self-assigned this 2024-03-24 21:54:44 -04:00

modulatingforce added 1 commit 2024-03-24 21:54:44 -04:00

writelock_issue afd7b7d387

modulatingforce added the

labels 2024-03-24 21:55:10 -04:00

modulatingforce commented

2024-03-24 22:49:52 -04:00

Author

Owner

I'm not sure why there's an issue. This is working without issues, and isn't stuck in a lock

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=760930700e12552e2fb31f363c75d41f

use tokio; // 1.36.0

use std::sync::Arc;
use tokio::sync::RwLock;

struct id {
    chattername : String,
}

struct bot {
    id : id
}

#[tokio::main]
async fn main() {
    
    
    println!("tester");
    
    // foo(a.clone()).await;
    // foo(a.clone()).await;
    // foo(a).await;
    
    let id_arc = Arc::new(RwLock::new(id{chattername : "Tester".to_string()}));
   /*
   // [x] SCENARIO 1 : A write() lock before the function that also calls write lock 
    let idlock = id_arc.write().await;
    foo(id_arc.clone()).await;
    */
    
    // [ ] SCENARIO 2 : Two lock functions - this works without issues
    // let idlock = id_arc.write().await;
    foo(id_arc.clone()).await;
    foo(id_arc.clone()).await;
    
}


async fn foo(a : Arc<RwLock<id>>) {

    println!("ACQUIRING LOCK");

    let mut idlock2 = a.write().await;
    idlock2.chattername = "tester2".to_string();
    
    println!("ACQUIRED LOCK");
    
}

I'm not sure why there's an issue. This is working without issues, and isn't stuck in a lock https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=760930700e12552e2fb31f363c75d41f ```rust use tokio; // 1.36.0 use std::sync::Arc; use tokio::sync::RwLock; struct id { chattername : String, } struct bot { id : id } #[tokio::main] async fn main() { println!("tester"); // foo(a.clone()).await; // foo(a.clone()).await; // foo(a).await; let id_arc = Arc::new(RwLock::new(id{chattername : "Tester".to_string()})); /* // [x] SCENARIO 1 : A write() lock before the function that also calls write lock let idlock = id_arc.write().await; foo(id_arc.clone()).await; */ // [ ] SCENARIO 2 : Two lock functions - this works without issues // let idlock = id_arc.write().await; foo(id_arc.clone()).await; foo(id_arc.clone()).await; } async fn foo(a : Arc<RwLock<id>>) { println!("ACQUIRING LOCK"); let mut idlock2 = a.write().await; idlock2.chattername = "tester2".to_string(); println!("ACQUIRED LOCK"); } ```

modulatingforce commented

2024-03-24 22:55:22 -04:00

Author

Owner

As a Potential Workaround, I may want to keep the following in mind

Keep IdentityManager.Can_User_Run() towards operations that initially call BotActions ; these starting areas of validation can can use write locks so to auto mod users
While not robust , for read only access (that does not change from the input command), use IdentityManager.getspecialroles()

// getspecialroles
    pub async fn getspecialuserroles(
        &self,
        chattername: String,
        channel: Option<Channel>,
    ) -> Vec<UserRole> {

At the moment, the following seems to not get stuck in a write lock in say_in_reply_to

        // let idlock = id.write().await; // <-- [ ] 03.24 - This is definitely locking it
        let idlock = id.read().await; // <-- [ ] 03.24 - seems to work
        let a = idlock.getspecialuserroles(params.get_sender(), Some(Channel(msg.channel_login.clone()))).await;

# As a Potential Workaround, I may want to keep the following in mind - Keep `IdentityManager.Can_User_Run()` towards operations that initially call `BotActions` ; these starting areas of validation can can use write locks so to auto mod users - While not robust , for read only access (that does not change from the input command), use `IdentityManager.getspecialroles()` --- ```rust // getspecialroles pub async fn getspecialuserroles( &self, chattername: String, channel: Option<Channel>, ) -> Vec<UserRole> { ``` --- At the moment, the following seems to not get stuck in a write lock in `say_in_reply_to` ```rust // let idlock = id.write().await; // <-- [ ] 03.24 - This is definitely locking it let idlock = id.read().await; // <-- [ ] 03.24 - seems to work let a = idlock.getspecialuserroles(params.get_sender(), Some(Channel(msg.channel_login.clone()))).await; ```

modulatingforce added 1 commit 2024-03-24 22:55:43 -04:00

(init) solution ab5624c6fa

modulatingforce added 2 commits 2024-03-24 23:43:05 -04:00

readlock fix cfadd73096

smol 8b3395c19a

modulatingforce commented

2024-03-24 23:44:02 -04:00

Author

Owner

Read only seems to work for now - will be merging

modulatingforce changed title from ~~WIP: writelock_issue~~ to writelock_issue

2024-03-24 23:44:04 -04:00