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

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
modulatingforce added the
Status
Need More Info
Priority
High
labels 2024-03-24 21:55:10 -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"); } ```
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
modulatingforce added 2 commits 2024-03-24 23:43:05 -04:00
Author
Owner

Read only seems to work for now - will be merging

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
modulatingforce merged commit 35db264b9e into parent-botaction-to-child-fn 2024-03-24 23:44:25 -04:00
modulatingforce deleted branch issue-chat-say-id-write-lock 2024-03-24 23:44:25 -04:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: modulatingforce/forcebot_rs#45
No description provided.