"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh6rqi$2o4e$1@digitaldaemon.com...
> > you don't need to de-fiber, they are cooperative so once you finish with
a
> > fiber (other than main) you delete it
> > the only reason to "fiberise" main is to allow you to get back to it.
the
> OS
> > could make all threads single fibers initially, but why when fiber use
is
> > rare. (same might be said for a process why have a process with a
thread,
> > why not have a process, that then has to do ConvertProcessToThread is
you
> > want threading)
>
> This is not true. (Don't ask me to explain, as this is all in an article that's yet-to-be-published, and I want to keep my powder dry. I'm know that's an *incredibly* lame thing to say, so I'm not going to attempt to press any points on this thread further.)
fine if your not going to explain I'll contine in ignorance of which bit of my conceptual overview of fiber, threads, process and sessions is wrong!!

> > fibers are a lot better than trying to do coroutines with
setjump/longjump
> > no manual manipulation of the stack
>
> Indeed. Fibers are great, and have lots of unforeseen uses. If only they were implemented a bit better in Win32, or, better, were a standard part
of
> C.
what more need to be done ?
with win32 fibers you can have several and jump between them :) see the
example pulled from MS's own docs on the subject

>
> I started a SourceForge project last year - http://fiberspp.sourceforge.net/ - but have yet to do anything. I'm
looking
> for talented people who know more about asm stuff than me to help me out
...
>
> > from my MS docs fibers are supported on win98+ and NT3.51 sp 3
>
> True, I forgot that.
>
> > you can have multipul fibers in a thread (my D test code had 3)
>
> Hmm. This does not correspond with my understanding and experience of
them.
> Can you post your code?
-----------------------------------------

import c.stdio;
import windows;

extern(Windows) {

alias void function( LPVOID ) LPFIBER_START_ROUTINE;
LPVOID CreateFiber(DWORD dwStackSize,LPFIBER_START_ROUTINE
lpStartAddress,LPVOID lpParameter);
VOID DeleteFiber(LPVOID lpFiber);
LPVOID ConvertThreadToFiber(LPVOID lpParameter);
VOID SwitchToFiber(LPVOID lpFiber);
BOOL SwitchToThread();
}

LPVOID lpFiber1;        // Addresses of each fiber that's created
LPVOID lpFiber2;
LPVOID lpFiber3;
LPVOID lpFiberMain;

extern (Windows) void FiberRoutine( LPVOID param )
{
 printf( " In fiber %u\n", param ); // Tell the world who we are
 if ( 1 == cast(DWORD)param ) {
  printf( " changing fiber 1->2\n" );
  SwitchToFiber( lpFiber2 );      // fiber1 -> fiber2
   } else if ( 2 == cast(DWORD)param ) {
  printf( " changing fiber 2->3\n" );
  SwitchToFiber( lpFiber3 );      // fiber2 -> fiber3
 } else if ( 3 == cast(DWORD)param ) {
  printf( " changing fber 3->main\n" );
  SwitchToFiber( lpFiberMain );   // fiber3->main fiber (original thread)
 }
 printf( " leaving fiber %u\n", param ); // Tell the world who we are
 printf( " returning to main fiber\n" ); // Tell the world who we are
 SwitchToFiber( lpFiberMain );   // fiber->main fiber (original)
 // if you don't end with this then you code will exit.
}

int main( char[][] argv )
{
    // Create 3 fibers, with starting addresses of the above routine
    lpFiber1 = CreateFiber( 16384, &FiberRoutine, cast(PVOID)1 );
    lpFiber2 = CreateFiber( 16384, &FiberRoutine, cast(PVOID)2 );
    lpFiber3 = CreateFiber( 16384, &FiberRoutine, cast(PVOID)3 );


    if ( !lpFiber1 || !lpFiber2 || !lpFiber3 )  // Make sure the fibers were
        return 0;                               // created

    // Make this thread a fiber, so that it can force the other fibers to
run
    lpFiberMain = ConvertThreadToFiber( cast(LPVOID)0 );

    // Sleep for 1 second, just to prove that the other
    printf( "Sleeping for 1 second\n" );
    Sleep( 1000 );

    printf( "Switching to first fiber\n" );
    SwitchToFiber( lpFiber1 );                  // Switch to fiber1
    printf( "Returning from SwitchToFiber ( fiber-1 )\n" );
    printf( "Switching to first fiber again\n" );
    SwitchToFiber( lpFiber1 );                  // Switch to fiber1
    printf( "Returning from (again) SwitchToFiber( fiber-1)\n" );

    DeleteFiber( lpFiber1 );    // Clean up the 3 fibers we created earlier
    DeleteFiber( lpFiber2 );
    DeleteFiber( lpFiber3 );

    return 0;
}
---------------------------------------------
straight port (+ a bit) from the MSDN

I'm going to have to study it a bit. Can you make it work on linux? Write a doc file for it?

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bh711f$2td5$1@digitaldaemon.com...
>
> import c.stdio;
> import windows;
> import object;
>
> extern(Windows) {
>
> alias void function( LPVOID ) LPFIBER_START_ROUTINE;
> LPVOID CreateFiber(DWORD dwStackSize,LPFIBER_START_ROUTINE
> lpStartAddress,LPVOID lpParameter);
> VOID DeleteFiber(LPVOID lpFiber);
> LPVOID ConvertThreadToFiber(LPVOID lpParameter);
> VOID SwitchToFiber(LPVOID lpFiber);
> }
>
> // T is the return type from the co-routine
> // U is the user context for the co-routine
> class CoManagerBase {
>  static LPVOID mainFiber = null;
>  Exception throw_me = null;
>  LPVOID this_fiber  = null;
>  bit delete_me      = false;
>
>  static void initForCoRoutines() {
>   if ( mainFiber === null ) {
>    mainFiber = ConvertThreadToFiber( null );
>   }
>  }
>  ~this() {
>   if ( this_fiber ) { endCoRoutine(); }
>  }
>  void createCoRoutine( LPFIBER_START_ROUTINE start_up ) {
>   assert( this_fiber === null );
>   this_fiber = CreateFiber( 16384, start_up, cast(LPVOID)this );
>  }
>  void yeildCoRoutine() {
>   assert( CoManagerBase.mainFiber );
>   SwitchToFiber( CoManagerBase.mainFiber );   // fiber->main fiber
> (original)
>  }
>
>  void deleteCoRoutine() {
>   assert( this_fiber );
>   DeleteFiber( this_fiber );
>   this_fiber = null;
>   delete_me  = false;
>  }
>
>  void endCoRoutine() {
>   delete_me = true;
>   SwitchToFiber( CoManagerBase.mainFiber );
>  }
>
>  void processCoRoutine() {
>   assert( this_fiber );
>   SwitchToFiber( this_fiber );
>  }
>
>  bit isActive() { return (this_fiber !== null); }
> }
>
> template coroutine( T, U ) {
>  alias void (*user_func)( CoManagerBase cm, U uservalue );
>
>  class CoManager : CoManagerBase {
>   user_func func;
>   U         value;
>   T         return_value;
>  public:
>   this() {
>    initForCoRoutines();
>   }
>   this( user_func func0, U user_value ) {
>    this();
>    begin( func0, user_value );
>   }
>   void begin( user_func func0, U user_value ) {
>    assert( isActive() == false );
>    func = func0;
>    value = user_value;
>    createCoRoutine( fiberCoRoutine );
>   }
>
>   void yield( T rv ) {
>    return_value = rv;
>    yeildCoRoutine();
>   }
>
>   void end( T rv ) {
>    return_value = rv;
>    endCoRoutine();
>   }
>
>   T process() {
>    processCoRoutine();
>    if ( throw_me )  { throw throw_me; }
>    if ( delete_me ) { deleteCoRoutine(); }
>    return return_value;
>   }
>  }
>  extern (Windows) void
>  fiberCoRoutine( LPVOID param )
>  {
>   CoManager cm = cast(CoManager)param;
>   cm.func( cm, cm.value );
>   while( true ){
>    cm.throw_me = new Exception( "CoRoutine overrun" );
>    SwitchToFiber( CoManagerBase.mainFiber );   // fiber->main fiber
> (original)
>   }
>  }
> // alias void function( CoManager mgr, U uservalue ) user_func;
> }
>
> struct Range { int start, end; }
> instance coroutine( int, Range ) cr_I_R;
> instance coroutine( int, int ) cr_I_I;
>
> void inc_by( CoManagerBase mgr, int incr ) {
>  int i = 0;
>  while(true) {
>   i += incr;
>   (cast(cr_I_I.CoManager)mgr).yield( i );
>  }
> }
>
> void counter( CoManagerBase mgr, Range r ) {
>  int i = r.start;
>  while( i < r.end ) {
>   (cast(cr_I_R.CoManager)mgr).yield( i );
>   i++;
>  }
>  (cast(cr_I_R.CoManager)mgr).end( i );
> }
>
> int main( char[][] argv )
> {
>  static Range r = { start:4, end:9 };
>  cr_I_I.CoManager coI = new cr_I_I.CoManager(
cast(cr_I_I.user_func)&inc_by,
> 11 );
>  cr_I_R.CoManager coR = new cr_I_R.CoManager(
cast(cr_I_R.user_func)counter,
> r );
>
>  printf( "being some corountines\n" );
>  while( coR.isActive() ) {
>   printf( "   incrementer : %d\n", coI.process() );
>   printf( "counter[range] : %d\n", coR.process() );
>  }
>  printf( "*done*\n" );
>
>  return 0;
> }
> ----------------
>
> how's that for proof that fibers are A easy and B do the job.
>
> >
> > I'd like to eventually add coroutines to D, but there are other things
> that
> > need to be done first. If you'd like to do a coroutine class, sort of
like
> > some of the C++ ones out there, that could become part of Phobos. It
could
> > hide the portability issues.
> >
>
> I've attached the versions I'd rather use (less casting) but form some
> reason (looks like a forward ref problem)
> I cant define two mutually dependant types within a template :(
>
>
>
>

> > This is not true. (Don't ask me to explain, as this is all in an article that's yet-to-be-published, and I want to keep my powder dry. I'm know that's an *incredibly* lame thing to say, so I'm not going to attempt to press any points on this thread further.)
> fine if your not going to explain I'll contine in ignorance of which bit
of
> my conceptual overview of fiber, threads, process and sessions is wrong!!

Oh no, I knew I'd come accross sounding like a tool. <blush>. I'm not trying to be a princess, but once you've signed over the rights to your article, you're not at liberty to go splashing the details in public until it comes out. I wish I'd never said anything now .... <glum>.

I certainly don't wish to imply you are ignorant of the subject. In fact, apart from the few areas in which I've used them, and found the pitfalls, I would state that I'm pretty ignorant of them.

(btw, I think I was using the wrong terminology earlier. I was using fiber for fiber-group. Naturally one can have many fibers; to only have one would be a bit pointless.)

> > Indeed. Fibers are great, and have lots of unforeseen uses. If only they were implemented a bit better in Win32, or, better, were a standard part
> of
> > C.
> what more need to be done ?
> with win32 fibers you can have several and jump between them :) see the
> example pulled from MS's own docs on the subject

Your example is, with respect, a little trivial. What if I want to create a fiber group with a certain peice of information, and use the (cooperative) multi-tasking nature to carry out some operation that must be done that way, and then later I want to do the same again. There's no SetFiberData(), so there's no way to start off a new fiber "task" (i.e a job involving a fiber group), unless I kick off a new thread (hardly the solution).

One option would be to have a fiber-data indirection, and then you can change the task information at some later stage. But in that case we would have to ensure that all fibers in our "group" would have finished with their use of the fiber data, and were back at an initialisable position. Not impossible, but not necessarily trivial.

Finally, all that is perhaps feasible when you're totally in control of all the code, but what about if it's in a library (either header, or via some API). You cannot turn a thread into a fiber twice, so if you have two libs making use of fibers the second one's going to die. (I can't remember whether the problem comes not with the second call to ConvertThreadToFiber() or on the next context switch, but I can tell you it does die.)

> > I started a SourceForge project last year - http://fiberspp.sourceforge.net/ - but have yet to do anything. I'm
> looking
> > for talented people who know more about asm stuff than me to help me out

Anyway, as I said, I'm not an asm-head, but am happy to learn from/cooperate with someone who is.

If anyone wants to create a cross-platform multi-fiber-group API (if such a thing is possible, of course, there're all those nasty stack guard page issues on Win32), then please shout up. It doesn't have to be on SourceForge, it could be a DMC/DMD thing.

Matthew

Just found the bits out of my article (it was written quite a long while
back):

"Unfortunately there is no way to close all the fibers without closing the
thread (i.e. there is no CloseThreadFiber() function), in other
words one cannot "de-fiber-ise" the thread. It is possible (at least on
Windows 2000) to ignore a previous initialisation
and call ConvertThreadToFiber() again, but the previously allocated fiber
management block remains allocated.
Although the MSDN knowledge base article Q185231 implies that one can simply
call LocalFree() on this block, this is
sailing far too close to the wind for me to recommend as a serious technique
to others (since it is not part of the
documented API, and therefore could be subject to breaking changes), and is
certainly not suitable for a robust and
flexible library.

Neither is it possible to call GetFiberData() in order to determine whether
fiber support has been initialised, as this
raises an access violation if it has not (and I don't like the hack of
catching that exception as the indicator), rather than
returning NULL; even if it were, the problems of interposing one fiber
sub-system on another would be inhibitive.

The hitch is, of course, what if some other part of the process is already
using fibers, or starts to use them during/after
the initialisation of our use of them? The simple and unappealing answer is
that it will crash. If two fiber sub-systems
run concurrently (within the scope defined by ConvertThreadToFiber() and the
exit from the calling thread) then the
second one to be initialised will destroy the execution contexts of the
first. If they run consecutively, then there will be a
memory leak (although it is only experience, as opposed to explicit
documentation on the subject, that lends this
understanding)"

Make sense? (I hope so, because that's what actually happens on all the Win32 OSs that I've tested it on.)

Matthew

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh7cqu$7v3$1@digitaldaemon.com...
> > > This is not true. (Don't ask me to explain, as this is all in an
article
> > > that's yet-to-be-published, and I want to keep my powder dry. I'm know that's an *incredibly* lame thing to say, so I'm not going to attempt
to
> > > press any points on this thread further.)
> > fine if your not going to explain I'll contine in ignorance of which bit
> of
> > my conceptual overview of fiber, threads, process and sessions is
wrong!!
>
> Oh no, I knew I'd come accross sounding like a tool. <blush>. I'm not
trying
> to be a princess, but once you've signed over the rights to your article, you're not at liberty to go splashing the details in public until it comes out. I wish I'd never said anything now .... <glum>.
>
> I certainly don't wish to imply you are ignorant of the subject. In fact, apart from the few areas in which I've used them, and found the pitfalls,
I
> would state that I'm pretty ignorant of them.
>
> (btw, I think I was using the wrong terminology earlier. I was using fiber for fiber-group. Naturally one can have many fibers; to only have one
would
> be a bit pointless.)
>
> > > Indeed. Fibers are great, and have lots of unforeseen uses. If only
they
> > > were implemented a bit better in Win32, or, better, were a standard
part
> > of
> > > C.
> > what more need to be done ?
> > with win32 fibers you can have several and jump between them :) see the
> > example pulled from MS's own docs on the subject
>
> Your example is, with respect, a little trivial. What if I want to create
a
> fiber group with a certain peice of information, and use the (cooperative) multi-tasking nature to carry out some operation that must be done that
way,
> and then later I want to do the same again. There's no SetFiberData(), so
> there's no way to start off a new fiber "task" (i.e a job involving a
fiber
> group), unless I kick off a new thread (hardly the solution).
>
> One option would be to have a fiber-data indirection, and then you can change the task information at some later stage. But in that case we would have to ensure that all fibers in our "group" would have finished with
their
> use of the fiber data, and were back at an initialisable position. Not impossible, but not necessarily trivial.
>
> Finally, all that is perhaps feasible when you're totally in control of
all
> the code, but what about if it's in a library (either header, or via some API). You cannot turn a thread into a fiber twice, so if you have two libs making use of fibers the second one's going to die. (I can't remember whether the problem comes not with the second call to
ConvertThreadToFiber()
> or on the next context switch, but I can tell you it does die.)
>
> > > I started a SourceForge project last year - http://fiberspp.sourceforge.net/ - but have yet to do anything. I'm
> > looking
> > > for talented people who know more about asm stuff than me to help me
out
>
> Anyway, as I said, I'm not an asm-head, but am happy to learn
from/cooperate
> with someone who is.
>
> If anyone wants to create a cross-platform multi-fiber-group API (if such
a
> thing is possible, of course, there're all those nasty stack guard page issues on Win32), then please shout up. It doesn't have to be on SourceForge, it could be a DMC/DMD thing.
>
> Matthew
>
>

>
> Your example is, with respect, a little trivial. What if I want to create
a
> fiber group with a certain peice of information, and use the (cooperative) multi-tasking nature to carry out some operation that must be done that
way,
> and then later I want to do the same again. There's no SetFiberData(), so
> there's no way to start off a new fiber "task" (i.e a job involving a
fiber
> group), unless I kick off a new thread (hardly the solution).
>
> One option would be to have a fiber-data indirection, and then you can change the task information at some later stage. But in that case we would have to ensure that all fibers in our "group" would have finished with
their
> use of the fiber data, and were back at an initialisable position. Not impossible, but not necessarily trivial.
>
> Finally, all that is perhaps feasible when you're totally in control of
all
> the code, but what about if it's in a library (either header, or via some API). You cannot turn a thread into a fiber twice, so if you have two libs making use of fibers the second one's going to die. (I can't remember whether the problem comes not with the second call to
ConvertThreadToFiber()
> or on the next context switch, but I can tell you it does die.)
>
the solution on Win32 is to use a thread local (contains the info to say that the thread has been fibered), and everyone use the same fiber library.

by fiber group, I assume you mean a fiber that creates other fibers that
"yield" to it rather than back to main ?
(easy to do).

> > Finally, all that is perhaps feasible when you're totally in control of
> all
> > the code, but what about if it's in a library (either header, or via
some
> > API). You cannot turn a thread into a fiber twice, so if you have two
libs
> > making use of fibers the second one's going to die. (I can't remember whether the problem comes not with the second call to
> ConvertThreadToFiber()
> > or on the next context switch, but I can tell you it does die.)
> >
> the solution on Win32 is to use a thread local (contains the info to say that the thread has been fibered), and everyone use the same fiber
library.

So you're saying the answer to the problem of the Win32 fiber implementation not supporting multiple "fiber-groups" is to not use multiple "fiber-groups". Well, yeah! That solves the problem, but means that the usefulness of Win32 fibers is dramatically curtailed.

Isn't that just a clearer statement of my proposition that Win32 fibers are not all that useful?

> by fiber group, I assume you mean a fiber that creates other fibers that
> "yield" to it rather than back to main ?
> (easy to do).

No, I mean that in your code you call some API function - we assume 3rd party - which merrily does some fiber stuff. The code then returns to you, and you carry on merrily, unaware that your thread has been "fiberised". At a later time you call another function - perhaps one of your own - that also makes use of fibers.

The minimum harm here is that you will have a memory leak (at least as far as current versions of Win32 is concerned; future ones may well crash at this point).

But what if the call to the 3rd party fiber-using API occurs after your fiber initialisation, and within the time that you are switching between the fibers. Crash!

Are you telling me that this is desirable functionality?

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh84p7$11vh$1@digitaldaemon.com...
>
> > by fiber group, I assume you mean a fiber that creates other fibers that
> > "yield" to it rather than back to main ?
> > (easy to do).
>
> No, I mean that in your code you call some API function - we assume 3rd party - which merrily does some fiber stuff. The code then returns to you, and you carry on merrily, unaware that your thread has been "fiberised".
At
> a later time you call another function - perhaps one of your own - that
also
> makes use of fibers.
>
this is the same as using GWL_USERDATA, only one person can. if you write a program that uses a library that uses it, you can't in your main app etc..

it does seem that GetCurrentFiber() is o.k. to call before you've converted
your thread to a fiber .....
strangly I get the value 0x00001E00 had expected null.

I see XP has `ConvertFiberToThread`
and server 2003 has ConvertThreadToFiberEx to allow the x86 fpu state to be
saved
as the NT fibers don't store FPU state (now that might be an issue, but I
would have though you would have flushed any FPU op's before yielding
anyway)
server 2003 also has Fiber local storage.

and from the win32 headers I deduced that FS:0x10 was the current fiber data pointer and that the first enty is a pointer to the FiberData so wrote SetFiberData and it works on Win2K (see test code)

I could see nothing in the Docs that implied that you can not call
ConvertThreadToFiber twice
but I made the assumption that the fiber state is only stored when you call
SwitchToFiber
and I was right, you can call convertThreadToFiber twice, and switch between
then ...
I've even tried manually setting the current fiber and the switching you can
create some fun loops :) the docs do mention that switching to current fiber
is not advisable but it does work as a way to set the return position of a
fiber. see the test doc. I felt like an afternoon of being abusive to win2K,
better than reading exchange docs on how write code to backup a server over
a network.

it would seem that if you call a library that uses fibers, and when it
returns the current fiber is not the same as it was, you can either manually
convert back to your main fiber and delete the one it was changed to, or
delete your created fiber and continue with the one you have now.
thus as I see it you can protect yourself for a lib that does not check that
the thread has been fiberised first
the docs mention that you can switch to a fiber of a different thread ...
now that opens up some fun doors.

I personally don't see anything that implies co-routines should not be written using fibers, just like any other interaction with the OS there are issuee for the user to consider.

It sounds like fibers have an ill-designed implementation, and are not ready for prime time. Besides, I may have found a neato way to do iterators without need of coroutines.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh7d5m$8ab$1@digitaldaemon.com...
> Just found the bits out of my article (it was written quite a long while
> back):
>
> "Unfortunately there is no way to close all the fibers without closing the
> thread (i.e. there is no CloseThreadFiber() function), in other
> words one cannot "de-fiber-ise" the thread. It is possible (at least on
> Windows 2000) to ignore a previous initialisation
> and call ConvertThreadToFiber() again, but the previously allocated fiber
> management block remains allocated.
> Although the MSDN knowledge base article Q185231 implies that one can
simply
> call LocalFree() on this block, this is
> sailing far too close to the wind for me to recommend as a serious
technique
> to others (since it is not part of the
> documented API, and therefore could be subject to breaking changes), and
is
> certainly not suitable for a robust and
> flexible library.
>
> Neither is it possible to call GetFiberData() in order to determine
whether
> fiber support has been initialised, as this
> raises an access violation if it has not (and I don't like the hack of
> catching that exception as the indicator), rather than
> returning NULL; even if it were, the problems of interposing one fiber
> sub-system on another would be inhibitive.
>
> The hitch is, of course, what if some other part of the process is already
> using fibers, or starts to use them during/after
> the initialisation of our use of them? The simple and unappealing answer
is
> that it will crash. If two fiber sub-systems
> run concurrently (within the scope defined by ConvertThreadToFiber() and
the
> exit from the calling thread) then the
> second one to be initialised will destroy the execution contexts of the
> first. If they run consecutively, then there will be a
> memory leak (although it is only experience, as opposed to explicit
> documentation on the subject, that lends this
> understanding)"
>
> Make sense? (I hope so, because that's what actually happens on all the Win32 OSs that I've tested it on.)
>
> Matthew
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh7cqu$7v3$1@digitaldaemon.com...
> > > > This is not true. (Don't ask me to explain, as this is all in an
> article
> > > > that's yet-to-be-published, and I want to keep my powder dry. I'm
know
> > > > that's an *incredibly* lame thing to say, so I'm not going to
attempt
> to
> > > > press any points on this thread further.)
> > > fine if your not going to explain I'll contine in ignorance of which
bit
> > of
> > > my conceptual overview of fiber, threads, process and sessions is
> wrong!!
> >
> > Oh no, I knew I'd come accross sounding like a tool. <blush>. I'm not
> trying
> > to be a princess, but once you've signed over the rights to your
article,
> > you're not at liberty to go splashing the details in public until it
comes
> > out. I wish I'd never said anything now .... <glum>.
> >
> > I certainly don't wish to imply you are ignorant of the subject. In
fact,
> > apart from the few areas in which I've used them, and found the
pitfalls,
> I
> > would state that I'm pretty ignorant of them.
> >
> > (btw, I think I was using the wrong terminology earlier. I was using
fiber
> > for fiber-group. Naturally one can have many fibers; to only have one
> would
> > be a bit pointless.)
> >
> > > > Indeed. Fibers are great, and have lots of unforeseen uses. If only
> they
> > > > were implemented a bit better in Win32, or, better, were a standard
> part
> > > of
> > > > C.
> > > what more need to be done ?
> > > with win32 fibers you can have several and jump between them :) see
the
> > > example pulled from MS's own docs on the subject
> >
> > Your example is, with respect, a little trivial. What if I want to
create
> a
> > fiber group with a certain peice of information, and use the
(cooperative)
> > multi-tasking nature to carry out some operation that must be done that
> way,
> > and then later I want to do the same again. There's no SetFiberData(),
so
> > there's no way to start off a new fiber "task" (i.e a job involving a
> fiber
> > group), unless I kick off a new thread (hardly the solution).
> >
> > One option would be to have a fiber-data indirection, and then you can change the task information at some later stage. But in that case we
would
> > have to ensure that all fibers in our "group" would have finished with
> their
> > use of the fiber data, and were back at an initialisable position. Not impossible, but not necessarily trivial.
> >
> > Finally, all that is perhaps feasible when you're totally in control of
> all
> > the code, but what about if it's in a library (either header, or via
some
> > API). You cannot turn a thread into a fiber twice, so if you have two
libs
> > making use of fibers the second one's going to die. (I can't remember whether the problem comes not with the second call to
> ConvertThreadToFiber()
> > or on the next context switch, but I can tell you it does die.)
> >
> > > > I started a SourceForge project last year - http://fiberspp.sourceforge.net/ - but have yet to do anything. I'm
> > > looking
> > > > for talented people who know more about asm stuff than me to help me
> out
> >
> > Anyway, as I said, I'm not an asm-head, but am happy to learn
> from/cooperate
> > with someone who is.
> >
> > If anyone wants to create a cross-platform multi-fiber-group API (if
such
> a
> > thing is possible, of course, there're all those nasty stack guard page issues on Win32), then please shout up. It doesn't have to be on SourceForge, it could be a DMC/DMD thing.
> >
> > Matthew
> >
> >
>
>

I'll bite.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bha2fs$5dq$1@digitaldaemon.com...
> It sounds like fibers have an ill-designed implementation, and are not
ready
> for prime time. Besides, I may have found a neato way to do iterators without need of coroutines.

Walter wrote:
> It sounds like fibers have an ill-designed implementation, and are not ready
> for prime time. Besides, I may have found a neato way to do iterators
> without need of coroutines.

I'm all ears.  I'd love to here about D's iterators.

Bill