Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

ngclient: Be better with concurrent instances

Đang mở
  • Có gì không ổn?
#2,836 7 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 10 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
python
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu bằng cách đọc luồng Updater của ngclient, đặc biệt là refresh(), get_targetinfo() và download_target(), đồng thời theo dõi nơi metadata và các tệp target được đọc hoặc ghi trong cache cục bộ. Xác định và ghi lại chính sách đồng thời giữa các tiến trình cho việc tạo lock, chờ, các lock cũ và phạm vi của lock; issue được hoàn thành khi các câu hỏi còn bỏ ngỏ đó có một hướng triển khai đã được thống nhất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Users may run multiple updaters at the same time -- it's not useful but it can happen with longer dependency chains like https://github.com/sigstore/sigstore-python/issues/1403: model-signing uses sigstore-python which uses python-tuf...

Currently we don't handle the potential conflicts WRT reading and writing metadata and target files to local cache that result from concurrent updaters. This is especially an issue with windows where concurrent file access leads to issues more often but it can be problematic in linux too -- this is why currently we just document Updater as "should be a singleton".

Possible improvement: lockfile

I think it makes sense to not try to solve this for just a single process but multiple real processes running updaters (something I can easily imagine happening in real life). In that case I think a lock file per repository would be best we can do:

  • check for lock file before reading/writing
  • create lock file, read/write, remove lock file

The reason this hasn't been done is that lockfiles are a pain to do especially cross platform.

Some open questions:

  • what to do when a lock file exists -- log a warning and wait (for how long?)? I don't usually like when libraries wait for things but maybe this works? What if the lock file is stale (let's say hours old)?
  • manually handling lockfiles in a way that works on windows is painful... but we've also done a lot of work to avoid unnecessary dependencies in this project. Using a dependency for this is likely the smaller evil
  • when exactly do we lock?
    • locking for lifetime of Updater probably has annoying side effects and is not expected by users
    • locking for duration of refresh() and get_targetinfo() seems logical at least at first glance. Locking for duration of download_target() is probably less important but could be done
Possible improvement: global state

If we are not interested in multiple processes but just multiple threads with updaters, we could always add some global state tracking... It sounds quite unappealing but possible. I feel like I'd rather advice python-tuf users to use ngclient Updater as a "per-repository-singleton"?

CC @spencerschrock, let me know if you have thoughts

Ngôn ngữ chính
Python
Star
1.7k
Fork
304
Merge trung bình
9 giờ 25 phút
Pull request đã merge (30 ngày)
14

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của theupdateframework/python-tuf

Tất cả issue của theupdateframework/python-tuf

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.