Re: [Minios-devel] [UNIKRAFT PATCH v2 4/8] lib/uksched: Introduce thread info

[Costin Lupu <costin.lup@xxxxxxxxx>]

Hi Florian,

On 1/23/19 3:45 PM, Florian Schmidt wrote:
> Hi Costin,
> 
> On 1/11/19 12:22 AM, Costin Lupu wrote:
> 
>> For example, a preemptive scheduler might define its custom info
>> like this:
>>
>> struct thread_info_preempt {
>>      struct thread_info_base base;
>>      prio_t prio;
>>      ...
>>
>> Similar to base constructor, the preemptive abstraction constructor
>> would look like this:
>>
>> struct thread_info_preempt *
>> thread_info_preempt_create(struct uk_alloc *a,
>>          struct uk_thread_attr *attr)
>> {
>>      struct thread_info_preempt *tip;
>>
>>      tip = uk_malloc(a, sizeof(struct thread_info_preempt));
>>      thread_info_base_init(&tip->base, attr); /* init base info */
>>      tip->prio = attr->prio;
>>      ...
> 
> I have to admit I'm still a bit confused by this explanation. The
> example you give is about a preemptive scheduler's priority. Why would
> it duplicate information that is already on the thread? Or is the idea
> that thread priorities might be of a different kind than the scheduler's
> priorities? But in that case, how would you set them properly,
> considering that pthread is the interface? If the scheduler had more
> classes than pthread allows, you could not properly use some of them; if
> it had less, it would have to merge some pthread classes anyway. Or what
> am I missing?

I decided to get rid of the thread info and only keep the detach flag on
the thread structure.

Regarding the priority classes, the frameworks I saw for applications
use the priorities defined by the scheduler (e.g. implementation of
pthread in different systems). For now, I'd suggest we keep these as
they are and address this, if the case, when we'll have more information.

Thanks,
Costin

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel