On Wednesday 23 May 2001 09:17, Micah Dowty wrote:
> 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.
So practically speaking, we have a way to talk to the event loop thread
already (buffer), we just have to make it thread safe by putting a lock
around that buffer. The only other piece that is needed is a way to tell the
event thread to recheck it's buffer, and exit. (A simple un-named pipe should
do the trick, signals and pthreads are very very ugly). So, something like
we hand pgEventThread a file descriptor that it adds to it's list of
"reader/select-ees", and it reads exit and re-read buffer instructions from
that. How does that sound? I'm thinking the actual pthread_ calls should be
stuffed in the application with the exception of the mutexes.
Hmm..., or we can get fancy, and stuff all the pthread_ stuff into the c
bindings, and do some smart work with adding stuff to the buffer that
triggers and "awake" to the fd. Yes, that's probably the "right" solution,
put it in the bindings so most people don't have to see it.
> 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?
Well, it's sort of indeterminate, gcc can use things other than posix
threads, but I am using posix threads (pthreads). Probably 90% of everything
out there is using posix threads too, so I don't see a major problem there.
Thanks,
Shane Nay.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
