[Bug 1620] Issues with rtems_libio_share_private_env at cpukit/libcsupport/src/privateenv.c

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1620

--- Comment #5 from Bharath Suri <bharath.s.jois at gmail.com> 2010-07-23 05:31:58 CDT ---
(In reply to comment #4)
> Created an attachment (id=907)
 --> (https://www.rtems.org/bugzilla/attachment.cgi?id=907) [details]
> Version of file with changes
> 
> How do these changes look?  If sharing with self and we already have a private
> environment, then I only see thress choices:
> 

I feel the check "rtems_current_user_env->task_id == current_task_id" does not
mean sharing with self. It is to check if the current task has a private
environment in place. 

The check "current_task_id == task_id" would mean an attempt to share with
self. In which case, I feel its best to return without doing anything.

> + consider it an error
> + delete private environment and go back to global
> + delete current private environment and set up a new one (new private env)
> 
> The first is a simple solution and might be the best.
> 
> I implemented the second solution in the privateenv.c attached.
> 
> The third can be accomplished if you delete your environment (option 2) and
> then readd the environment by the normal call.
> 
> Suggestions and comments welcomed.

>From what I could understand from the requirement, I could manage to put this:

- Get the current_task_id
- If the task_id == current_task_id, return
- Get the current usr env in to a temporary location
- Try to get the remote task's current usr env variable into the
shared_user_env
- If success, free the current user env variable through the temporary
location, and assign "rtems_current_user_env = shared_user_env"
- If we could not get the remote task's usr env variable, return ( no changes
to current user env variable )

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.