Re: [Pybeep-devel] updates: scheduler and stuff

[Sean A. <ze...@wo...>]

On Fri, 2002-03-01 at 04:29, Gabe Wachob wrote:
> Checked in a bunch of edits to the core stuff tonight (er, its 4:20am -
> thats morning I guess).

Up late eh? ;-)

> Basically, I wrote the scheduler, and added in the hooks to the channel
> code. Added some new listener/event types and added some methods to the
> channel. The main thing left with that is to refactor sendToPeer to queue
> up messages in the outgoingMQueue instead of trying to directly write
> frames to the session. The scheduler will be called to "grab" frames from
> channels which are ready to write, instead of simply being dumped frames
> from channels as the channels feel the desire.

This all looks pretty cool. I have been sketching out a few ideas for
the session end of it in my head, I guess now it'll be a lot easier.

> I also fixed some little bugs that were breaking test cases. I didn't
> write any test cases for the new code commited (bad me), but that is
> definitely on my list.

Wow.. all the tests run OK....

> I'm happily surprised to see that most of the complicated code in the cor=
e
> of channel is for getting data in from the wire and sending it to
> profiles, which is something I'm leaving untouched - its just the path of
> data from the profiles through channels to the session and the wire which
> is getting a makeover. Its turning out to be pretty straightforward and
> maybe something the java beepcore people might consider.
>=20
> I was also thinking about threading - I think there are essentially two
> threads in the core plus whatever threads one desires in the app space.
> The two threads are a reader (ie from the wire to the channels/profiles)
> and a writer (which the the scheduler who takes data from the
> profiles/channels and puts them on the wire to the remote peer).
>=20
> I didn't get any reaction to my last posting about the architectural
> diagrams I posted http://pybeep.sourceforge.net/arch.png, so I'm assuming
> its understandable and there aren't any issues. Its now largely
> implemented, or at least sketched out in code.

Yes, it was all pretty clear

 > I know that I had divied up this task list to Sean and Huston, but I hav=
e
> not heard from you guys in a little while and I thought it would be easie=
r
> to pound this stuff out in code rather than try to go too much farther
> describing it.

Ahh, well, I've had to put a lot of time into the ol' job hunt, but
thankfully I have this weekend to myself again, so...

> Anyway, as always, the source  is your best bet at this point.
>=20
> I'm thinking we need to do a major code cleanup (stylewise, naming,
> commenting, etc) and I'd like someone who has more energy for that to be
> the lead, if someone would be so kind.

I'd be keen, I like that kind of stuff anyway.

> Hopefully I didn't step on anybody's plate of work here....

Glad to see you're feeling better

One thing I have run into in terms of using the incremental parser, is
that the object you need to hand to it definitely needs to have a file
interface (I have yet to dig deeper into this 'cos of time) so that is
something to consider, if anyone is working on streams at the moment. We
need to finalize what we are going to hand to the parser. (i.e.
stream.getData(), or just give it the stream, or
stream.getData().getByteStream() or whatever)

Sean