----- Original Message ----- > From: "Alexander Stavonin" <a.stavo...@gmail.com> > To: "Brian Anderson" <bander...@mozilla.com> > Cc: rust-dev@mozilla.org > Sent: Tuesday, May 1, 2012 5:18:56 PM > Subject: Re: [rust-dev] Testing facility and shared data > > Unfortunately, I didn't caught your idea with with_fixture :( I have > next situation, may be you have an idea how to fix it: > > I need to allocate unique TCP ports numbers for each test. In case of > C/C++ solution is extreamly easy: create singleton or static > variable and just atomically increase last_used_port value for each > test. Do you have idea how to make it in case of Rust? I thought > about external C library for storing static data, but it is dirty > hack. May be would better to use singleton tasks ? Could you point > me into singleton tasks inside core library?
OK. Here are some short-term options. They are all bad. 1) If you only need the unique port numbers to avoid collisions when running in parallel then we can come up with a way to run the tests in serial, allowing you to reuse port numbers. A hack to do this is by setting the RUST_THREADS environment variable to 1. When there is only 1 scheduler thread the test runner will run tests serially. There may be other ways to achieve this kind without too much work. 2) If you just need to generate a unique integer in every test then write `unsafe::reinterpret_cast(task::get_task_id())`. This is a huge hack, but task id's are unique, pointer-sized, unsigned integers that start at 0 and increase monotonically. If you need many unique uints per task then do the same thing but use channels instead of tasks. 3) We can come up with a public API to create global, singleton tasks, possibly with the following signatures: unsafe fn register_named_service<T>(n: str, f: fn~(port<T>)) unsafe fn get_named_service<T>(n: str) -> chan<T> This would, if the named service doesn't exist, create a new task and execute the specified function. You would use this in each test to create or retrieve a global service to manage your state. The big reservation I have about this is that we can not currently make this interface type safe - we can't even check the types at runtime. -Brian _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev