Well, it sounds like what needs to be done here is adding thread support to the C client library. It shouldn't require threads, because that would reduce portability. There could be a compile-time (or maybe even run-time) option to enable thread support. When PicoGUI requests are sent to the server, they are stored in a buffer. When the buffer is full or it is flushed (by pgFlushRequests for example) the packets are sent to the server. If a lock were placed around key non-reentrant functions like _pg_add_request and pgFlushRequests, requests should be sent correctly from any thread. This is something that could be added at compile time if threads are available, and wouldn't effect the operation of single-threaded programs. I am assuming that event handlers could run in a new thread, and that the event loop could be a separate thread. This could be useful in many circumstances, but it would change the programming model because events and event loops would return immediately. So, how about a new set of calls, pgEventThread and pgExitEventThread. They could generally act the same as pgEventLoop and pgExitEventLoop, but the event loop itself would be a separate thread, and handlers would run in a new thread. If this all sounds reasonable, it should be easy to implement in cli_c. I'd just have to learn a bit more about multithreaded programming. Are you using pthreads, or something else? On Thu, 24 May 2001, Shane Nay wrote: > > Pgui-ers, > > Okay, I've finally gotten libgcj to do some basic heavyweight drawing, Labels > and Buttons are presently functional. The application formation method is > ugly to the n-th degree, and implementing proper sizing and location is going > to be a pain in the behind. But the initial connections to the drawing > engine are done, and layed out pretty well. Once I get a smarter way for > laying out widgets, and get something other than the default theme installed > I'll take some screenshots, and post a new code snapshot. (Things have > changed a lot, and I've got a patch for the Makefile.am and configure.in for > gcc to hook everything together) > > Now, the question I have now relates to threading. The way the Event stuff > works within libgcj is something like this I'm pretty sure: Events are gotten > and mangled in the GUI specific thread (pgEventLoop()), and dispatched > through some IPC mechanism to one of the core java threads. Now if that's > going to function for our purposes, we'll also need to pipe over drawing > requests through a dispatch system to the pgEventLoop thread I'm pretty sure. > (Micah correct me if I'm wrong on this) > > One of the ideas I have for solving this problem is something like this..., > just change the core c bindings to do things a little differently. Make them > smart about which thread they are in, if they are in the one that actually > does the talking to the server, things progress as normal. If not, they pass > a message to that thread which fits in with it's select call somehow and pass > the data to be piped to pgserver. > > What do you think? Any other ideas for how to solve the "Whos drawing where" > problem? I'm just sort of brainstorming at this point, I'm not going to > solve this problem until I have a good layout method. (Week or two away..., > I got side tracked trying to fix a bug in gcj, but just did a work around > instead when I got tired of screwing around with debug'ing RTL code trees) > > Thanks, > Shane Nay. > > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/pgui-devel -- To the systems programmer, users and applications server only to provide a test load. _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/pgui-devel
