Tại sao tệp tin xử lý tài nguyên đắt tiền như vậy?

Question

Trong các cuộc chiến tranh thánh về việc liệu thu gom rác là một điều tốt hay không, mọi người thường chỉ ra rằng nó không xử lý những thứ như giải phóng các tập tin xử lý. Đặt logic này trong finalizer được coi là một điều xấu vì tài nguyên sau đó được giải phóng không xác định. Tuy nhiên, nó có vẻ là một giải pháp dễ dàng cho hệ điều hành để đảm bảo rất nhiều và rất nhiều tập tin có sẵn để chúng là một nguồn tài nguyên giá rẻ và phong phú và bạn có thể lãng phí một vài tại bất kỳ thời điểm nào. Tại sao điều này không được thực hiện trong thực tế?

Answer 1

Đóng tệp cũng xóa ghi vào đĩa - tốt, từ quan điểm của ứng dụng của bạn. Sau khi đóng một tệp, ứng dụng có thể gặp sự cố, miễn là bản thân hệ thống không bị lỗi, các thay đổi sẽ không bị mất. Vì vậy, nó không phải là một ý tưởng tốt để cho GC đóng các tập tin lúc giải trí của nó. Ngay cả khi nó có thể là kỹ thuật có thể ngày nay.

Ngoài ra, để nói sự thật, thói quen cũ chết cứng. Tập tin xử lý được sử dụng để được đắt tiền và vẫn có thể được coi là như vậy vì lý do lịch sử.

Answer 2

Nó không chỉ là số lượng xử lý tệp, mà đôi khi chúng được sử dụng ở một số chế độ, chúng có thể ngăn người gọi khác truy cập vào cùng một tệp.

Answer 3

Tôi chắc chắn rằng các câu trả lời toàn diện hơn sẽ xảy ra, nhưng dựa trên kinh nghiệm hạn chế và sự hiểu biết về hoạt động cơ bản của Windows, các tệp xử lý (cấu trúc được sử dụng để đại diện cho hệ điều hành) là các đối tượng hạt nhân. một loại bộ nhớ nhất định có sẵn - chưa kể đến việc xử lý trên phần hạt nhân để duy trì sự nhất quán và kết hợp với nhiều quy trình yêu cầu truy cập vào cùng một tài nguyên (ví dụ: tệp)

Answer 4

Tôi không nghĩ rằng chúng nhất thiết phải đắt tiền - nếu ứng dụng của bạn chỉ chứa một vài ứng dụng unnessary thì nó sẽ không giết hệ thống. Cũng giống như nếu bạn chỉ rò rỉ một vài chuỗi trong C++, không ai sẽ chú ý, trừ khi họ đang tìm kiếm khá cẩn thận. Trong trường hợp nó trở thành một vấn đề là:

• nếu bạn bị rò rỉ hàng trăm hoặc hàng ngàn
• nếu có mở tập tin ngăn chặn các hoạt động khác xảy ra trên tập tin đó (các ứng dụng khác có thể không có khả năng mở hoặc xóa các tập tin)
• đó là dấu hiệu của sự cẩu thả - nếu chương trình của bạn không thể theo dõi những gì nó sở hữu và đang sử dụng hoặc đã ngừng sử dụng, chương trình sẽ có những vấn đề gì khác? Đôi khi một rò rỉ nhỏ biến thành một sự rò rỉ lớn khi một cái gì đó thay đổi nhỏ hoặc một người sử dụng làm một cái gì đó hơi khác so với trước đây.

Answer 5

Trong thực tế, nó không thể được thực hiện bởi vì hệ điều hành sẽ phải phân bổ nhiều chi phí bộ nhớ hơn để theo dõi xử lý nào đang được sử dụng bởi các quy trình khác nhau. Trong một ví dụ mã C như hình dưới đây tôi sẽ chứng minh một cấu trúc quy trình hệ điều hành đơn giản được lưu trữ trong một hàng đợi tròn cho một ví dụ ...

 
struct ProcessRecord{ 
    int ProcessId; 
    CPURegs cpuRegs; 
    TaskPointer **children; 
    int *baseMemAddress; 
    int sizeOfStack; 
    int sizeOfHeap; 
    int *baseHeapAddress; 
    int granularity; 
    int time; 
    enum State{ Running, Runnable, Zombie ... }; 
    /* ...few more fields here... */ 
    long *fileHandles; 
    long fileHandlesCount; 
}proc; 

Hãy tưởng tượng rằng fileHandles là một con trỏ đến một mảng các số nguyên mà mỗi số nguyên chứa vị trí (có thể ở định dạng được mã hóa) để bù vào bảng của hệ điều hành nơi tệp được lưu trữ trên đĩa.

Bây giờ hãy tưởng tượng dung lượng bộ nhớ sẽ tăng lên và có thể làm chậm toàn bộ hạt nhân, có thể mang lại sự mất ổn định vì khái niệm 'đa tác vụ' của hệ thống sẽ giảm do phải theo dõi bao nhiêu Filehandles được sử dụng và cung cấp một cơ chế tự động tăng/giảm con trỏ đến các số nguyên có thể có tác dụng làm chậm chương trình người dùng nếu hệ điều hành đã xử lý các tập tin trên cơ sở nhu cầu của chương trình người dùng.

Tôi hy vọng điều này sẽ giúp bạn hiểu tại sao nó không được triển khai hoặc không thực tế.

Hy vọng điều này có ý nghĩa, Trân trọng, Tom.

Answer 6

Trong các ổ cắm mô hình Linux là các bộ mô tả tệp. Có những ưu điểm nhất định để giải phóng các cổng TCP càng sớm càng tốt.