From: Jochen Kalmbach [MVP] on
Hi Leo!

> AFAIK the fibers themselves can move between threads. The things you
> may want to run *on* fibers may have thread affinity and cause
> problems (e.g. apartment threaded COM objects) but you'd have those
> problems with any mechanism which moved code calling those things
> between threads.
>
> Can't say that I've ever used fibers, since they only make sense to a
> very tiny niche which I've never found myself in, but that's my
> understanding of them.

I use fibers alot, and it works great! There are no problems with
multiple-threads and fibers...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
From: Chris Becke on
On 29/04/2010 06:23, olk wrote:
> m schrieb:
>> I am curious why you think that it is a good idea to build this?
>
> Ofcourse - I got my lib working on several UNIX systems. Only Windows
> makes it difficult.
>
> It
>> will be 1) hard;
>
> probably
>
> 2) fragile and is probably, like fibers, mostly useless.
>
> WIN32 Fibers are uselees because not migrateable between threads.

They arn't? Ooops.

Someone should tell Raymond:
http://blogs.msdn.com/oldnewthing/archive/2010/02/25/9969014.aspx

> The lib I try to create provides 'continuations'/'coroutines' for C++
> (similiar to features of GO, Python -> call/cc).

and fibers are fantastic for this. I face the inverse task of trying to
port my co-routines with fibers approach to linux & Mac OS.
From: Hector Santos on
Jochen Kalmbach [MVP] wrote:

> Hi Leo!
>
>> AFAIK the fibers themselves can move between threads. The things you
>> may want to run *on* fibers may have thread affinity and cause
>> problems (e.g. apartment threaded COM objects) but you'd have those
>> problems with any mechanism which moved code calling those things
>> between threads.
>>
>> Can't say that I've ever used fibers, since they only make sense to a
>> very tiny niche which I've never found myself in, but that's my
>> understanding of them.
>
> I use fibers alot, and it works great! There are no problems with
> multiple-threads and fibers...

Can you cite some practical usage examples? How it helps? thanks.

--
HLS
From: Jochen Kalmbach [MVP] on
Hi Hector!

>> I use fibers alot, and it works great! There are no problems with
>> multiple-threads and fibers...
>
> Can you cite some practical usage examples? How it helps? thanks.

What do you mean? SwitchToFiber / CreateFiber / ConvertThreadToFiber?
These function are not tooo complicated.

If you need some advantage out of these functions, you need to "build"
alot infrastructure around these functions....
I have here a completely multi-tasking-system (cooperative) which also
supports "free threading tasks". You can join/leave tasks from the
cooperative system...

It is very helpfull if you have many tasks, but you will not care about
multi-threading. I use it for a "real-time" program on XP.

Or what exactly do you want to see?

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
From: Hector Santos on
Jochen Kalmbach [MVP] wrote:

> Hi Hector!
>
>>> I use fibers alot, and it works great! There are no problems with
>>> multiple-threads and fibers...
>>
>> Can you cite some practical usage examples? How it helps? thanks.
>
> What do you mean? SwitchToFiber / CreateFiber / ConvertThreadToFiber?
> These function are not tooo complicated.


But how are they applied, when are they useful? What purpose do they
serve? When can they apply or don't?

Reading wikipedia

http://en.wikipedia.org/wiki/Fiber_(computer_science)

gave a basic understanding to see/how they are may be applicable.

> If you need some advantage out of these functions, you need to "build"
> alot infrastructure around these functions....
> I have here a completely multi-tasking-system (cooperative) which also
> supports "free threading tasks". You can join/leave tasks from the
> cooperative system...
>
> It is very helpfull if you have many tasks, but you will not care about
> multi-threading. I use it for a "real-time" program on XP.


Ok, that is a good practical example where it may be applied.

> Or what exactly do you want to see?


Case scenarios, like "real time" example where you need, I guess more
predictability with "Fiber Residence Time."

I never used them, but reading about them (briefly) in the past, I
always thought where it might be useful is to split thread work within
a thread. I had the idea it was something like:

Fiber1
Process -> Thread --> Fiber2
...
FiberX

Where a thread needed to do X jobs quickly with minimum stack overhead
before it can continue.

But as MSDN stated:

"In general, fibers do not provide advantages over a well-designed
multithreaded application."

I didn't think I would need it.

I'm also doing a lot more with IOCP and I/O based thread scheduling,
so your comment spiked my interest if FIBERS are useful for the work I
am doing (or not). If I understand it more, it sounds fibers can
degrade the improvements gained with IOCP optimized thread scheduling?

--
HLS