----- Original Message -----
> From: "Alexander Stavonin" <[email protected]>
> To: "Brian Anderson" <[email protected]>
> Cc: [email protected]
> 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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
