I was trying to be too clever with git-sendmail and I accidentally sent
that message to the wrong list. Please ignore it. Sorry about that.
- Neil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
Jason wrote:
> Kristian and I were looking at this today, and there seems to be a
> substantial race in the way that we are doing texture locking.
Yes, it does look like this is a problem. I also noticed another
dodgy-looking pattern when implementing the GL_ARB_clear_texture
extension. Whenever
Previously if the output had a transform then the cursor plane would
be disabled. However as we have to copy the cursor image into a buffer
with the CPU anyway it probably won't cost much extra to also apply
the transform in the process and then we can avoid disabling the
plane.
If the transform i
Version 2 of the patch makes the following changes:
• The patch is reordered to be on top of the patch to handle
wl_output.release so that it doesn't need to have a dummy marker for
zombifying without a destructor.
• The destructor opcode is stored in the implementation pointer rather
than
Here is a version two of the patch which is just needed so that the
patches can be reordered and this can come before the patch to handle
zombies.
--- >8 --- (use git am --scissors to automatically chop here)
The wl_output.release request is now handled. It just causes the
resourc
Here is a version two of the patch which moves the macro to
wayland-server.h and fixes a typo in the docs.
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
This adds a macro called WL_REQUEST_OPCODE which takes the name of the
struct for the interface and the
This gets the implementation for a resource that was set in the
implementation argument of wl_resource_set_implementation or
wl_resource_set_dispatcher. This is mostly useful in conjuction with a
dispatcher which may want to dispatch via the implementation pointers
or just store some extra informat
Jason Ekstrand writes:
> The destructor passed in here should be 0, why is it ~0? Also, it
> might be a good idea to throw it in a #define or enum for clarity.
The ~0 is meant to signify ‘there is no destructor’, ie, it's a fake
opcode that will never match a request. The reason is that I put th
Jason Ekstrand writes:
> Yeah, these are the wrong semantics. If they specify an output and it
> turns out to be a zombie, we should do nothing. A null output in
> wl_fullscreen_shell.present_surface means "put it somewhere". In the case
> of weston's implementation, it goes on all outputs. W
Jason Ekstrand writes:
> Ooh, I like this. I thought about having wayland-scanner emit more
> #defines, but this works rather nicely. One question: do we want it in
> wayland-util or wayland-server? Putting it in wayland-util exposes it
> client-side as well.
> --Jason
Yeah, I agree, perhaps
This adds a macro called WL_REQUEST_OPCODE which takes the name of the
struct for the interface and the name of one of its members. It then
calculates the opcode number by dividing the offsetof the member by
the size of a function pointer. This assumes the interface struct only
contains function po
The wl_output.release request is now handled. It just causes the
resource to be destroyed. This is also set as the destructor when
zombifying the resource.
---
src/compositor.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/compositor.c b/src/compo
Outputs can come and go within the compositor. If we don't have a way
for the client to destroy the resource then the resources within the
compositor will effectively leak until the client disconnects. This is
similar to the release event for wl_pointer.
---
protocol/wayland.xml | 8 +++-
1 fi
Previously when an output was unplugged the clients' resources for it
were left around and if they were used in a request it could cause
Weston to access invalid memory. Now when an output is unplugged the
resources for it are marked as zombies. This is done by setting a
dummy dispatcher and settin
Hi,
Srivardhan Hebbar writes:
> +AC_PATH_PROG([wayland_scanner], [wayland-scanner],,
> + [${WAYLAND_SCANNER_PATH}])
I don't think it makes much sense to search the path for wayland-scanner
when pkg-config already gives you the complete filename. Instead of
trying to derive a directo
After looking at it a bit more I don't think we can really make the
automatic zombie idea work. The trouble is that libwayland-server would
need to know when the client has destroyed the proxy in order to destroy
the zombie resource. However the destroy semantics are
interface-dependent so only an
Jason Ekstrand writes:
> Most of the magic there is in allowing resources with no handler in
> libwayland-server. The patch would be about 4 lines. Right now,
> client-side wl_proxy objects are allowed to have a NULL implementation
> and there's no problem; server-side, this is not currently allo
Perhaps we should consider applying the patch anyway even though it's
not ideal. Currently if a client uses a dead output in a request such as
xdg_surface.set_output Weston will end up with a weston_output pointer
that points to freed memory. This could cause the compositor to crash.
That is worse
When an output is destroyed it now also destroys any resources that
were pointing to it. Otherwise if the resource is destroyed after the
output then the resource would try to remove itself from the resource
list but the head of the resource list would no longer be valid and it
would write to inval
Oh no, I didn't notice this patch buried in the patch series and
implemented the same thing:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/014690.html
Ander, it would be really helpful if you could leave a little note on
the bug report if you post a patch to reduce that chance that
Previously simple-touch would only handle one seat. If there were
multiple seats it would lose track of whether there is a touch device
available depending on what order the capability events arrive in.
This makes it keep a linked list of seats and to track a separate
touch device for each seat so
The zoom translation is just a scale and a translate. The translation
is calculated based on the coordinates of the pointer which are in
global space. Previously the calculated translation was transformed by
the output transformation so that when the zoom transform is applied
after the output trans
Pekka Paalanen writes:
> were you aware of […] perhaps? :-)
Ah, no, I hadn't noticed those patches. Oops!
> Your series is almost identical to Quanxian's, except:
> - wording differences, of course
> - patch 2 checks if output->name is set before sending (can it ever be
> NULL?)
> - patch 2 m
Bill Spitzak writes:
> 1. It would seem more useful for the desktop shell to send some info
> about how the client was launched in environment variables.
Yes, maybe it would be cleaner to agree on some protocol for the parent
process to send the information directly to the child. I'm not sure
ab
Hi,
Currently Weston has a problem that it always puts new surfaces on the
same output as the one the first pointer is in. I guess the idea is that
most of the time surfaces are created as a result of mouse events and
there is usually only one pointer so it works most of the time. However
of cours
If the scale for the cursor surface doesn't match that of the output
then we shouldn't use the cursor overlay because otherwise it will be
drawn at the wrong size. This problem is particularly noticable with
multiple pointers because it randomly alternates between drawing one
cursor or the other at
When converting output-relative coordinates (such as from an input
event) to global coordinates it now takes into account the zoom
transform. Previously this would only work for the primary pointer
because the transform doesn't affect the primary pointer position due
to that way zoom follows the mo
If the compositor supports version 3 of the wl_output interface and
sends a name event then this will now be displayed in the info.
---
clients/weston-info.c | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/clients/weston-info.c b/clients/
This version for the wl_output interface has been changed to 3 and it
now sends out the name event when a client binds an output.
---
src/compositor.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index ee8dc24..6a333df 100644
--- a/src
This bumps the version of the wl_output interface to 3 and adds a
separate event to report the output's name.
---
protocol/wayland.xml | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 330f8ab..60fa81e 100644
--- a/p
In order to apply the zoom transformation to the output matrix, Weston was
doing the following:
• Create a temporary matrix to hold the translation
• Invert the translation matrix using weston_matrix_invert into
another temporary matrix
• Scale that matrix by the scale factor
• Multiply the curr
I think I wrote the goto handled code. The advantage of that over
putting the assert in the default handler is that if a new event type is
added to the evdev_event_type enum then GCC will give a nice warning for
that switch statement so we'd know we need to add a handler for it.
I think I would pe
It looks like the handler for frame events from the wl_touch interface for
widgets may have been erroneously copied from the cancel handler so that it
removes all handlers as they are processed. I don't think this makes much sense
for the frame event. This was stopping the panel icons from being pu
I think we accientally wrote nearly identical patches at the same time:
http://lists.freedesktop.org/archives/wayland-devel/2014-April/014392.html
However, I still get the crash with Ander's patch because it looks like
it is missing the check for wl_list_empty in the libinput-seat.c version
of de
Commit 4ade0e4a29 changed the order of initialising the seats and outputs so
that the seats would be done before the outputs. However the device_added
function in libinput-seat and udev-seat which gets called during initialisation
was trying to use the output list to assign an output to the device.
It looks like this patch makes Weston crash on touch events.
The device_added functions in udev-seat.c and libinput-seat.c try to use
the output list in order to assign the output for the newly created
device. These functions get called via udev_input_init so I guess that
means this function and c
"Jasper St. Pierre" writes:
> Why is this necessary? Won't events never be delivered while locked
> anyway?
Events do seem to get delivered, you can try it if you run weston -i5
and then open a terminal and let it lock. You can still type in the
terminal and launch programs.
But yeah, I guess a
Before commit 2f5faff7f9142 when the compositor is locked it would
reset the keyboard focus on all of the seats as part of pushing the
focus_state. This was removed because it now always keeps track of the
focus_state in the workspace instead of waiting until the state is
pushed. However this had t
The focus_state list on a workspace only contains entries for seats
which have a keyboard focus on that workspace. For workspaces that
have no surfaces the list will be empty. That means that when a
workspace with no surfaces is switched to it would previously leave
the keyboard focus unaffected an
I think this could be really useful. I've struggled a few times trying
to filter the output from WAYLAND_DEBUG=server when I only want to know
about a particular client.
Pekka Paalanen writes:
> - Some messages carry file descriptors. Is it possible to write a
> proxy without having the protocol
Jason Ekstrand wrote:
> We may still have a problem if the client changes buffer formats
> mid-stream. Say it starts out with RGB565 to save memory but latter
> decides it wants alpha so it switches to ARGB. We should
> probably detect this and make sure glTexImage2D gets called again to
> res
Previously when uploading SHM data we would initialise the texture
with glTexImage2D and NULL data when the buffer is attached. Then if
the GL_EXT_unpack_subimage extension is available we would always use
glTexSubImage2D to upload the data. The problem with that is that the
first glTexImage2D was
Kristian Høgsberg writes:
> Thanks Neil, series applied to mesa and weston.
Great, thanks!
I've reposted the piglit patch to the piglit list in case someone wants
to review it there.
Regards,
- Neil
___
wayland-devel mailing list
wayland-devel@lists.
In GLES 3 it is not possible to select rendering to the front buffer and
instead selecting GL_BACK has the magic interpretation that it is either the
front buffer on single-buffered configs or the back buffer on double-buffered.
GLES 1 and 2 have no way of selecting the draw buffer at all. In that
Under GLES 3 it is not valid to pass GL_FRONT to glDrawBuffers. Instead,
GL_BACK has a magic interpretation which means it will render to the front
buffer on single-buffered contexts and the back buffer on double-buffered. We
were incorrectly setting the initial value to GL_FRONT for single-buffere
Here is a series of patches to add an extension which makes it
possible to create an EGL context without specifying a config. A
context created in this way can be bound with any surface using the
same EGLDisplay rather than being restricted to those using the same
config. The main use case is that
The gbm-format configuration option can now be specified per-output as
well as in the core config section. If it is not specified it will
default to the format specified in the core section. The
EGL_MESA_configless_context extension is required for this to work. If
this extension is available it wi
Part of the gl_renderer_setup function only deals with checking EGL
extensions and doesn't need to have a current context. This patch
moves these checks so that they are done during gl_renderer_create
instead of waiting until we have an output. We will need this in a
later patch because some of the
EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors
In eglCreateContext there is a check for whether the config parameter is zero
and in this case it will avoid reporting an error if the
EGL_KHR_surfacless_context extension is supported. However there is nothing in
that extension which says you can create a context without a config and Mesa
breaks i
/null
+++ b/docs/specs/MESA_configless_context.spec
@@ -0,0 +1,120 @@
+Name
+
+MESA_configless_context
+
+Name Strings
+
+EGL_MESA_configless_context
+
+Contact
+
+Neil Roberts
+
+Status
+
+Proposal
+
+Version
+
+Version 1, February 28, 2014
+
+Number
+
+EGL Extension #not
Here is a second version of the patch to match with the changes in v2
of the extension.
Regards,
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
This adds a separate nested client to the weston-nested example which
will create YUV buffers using libva. The cod
The subsurface widgets on the nested example aren't using Cairo to
render so we should turn it off to prevent the toy toolkit from
creating a redundant extra surface for it. This is particularly
important since Mesa commit 6c9d6898fdfd7e2 because the surface that
the toolkit tries to create is zero
emory or an unsupported pixel
format.
@@ -99,3 +143,6 @@ Revision History
Initial draft (Neil Roberts)
Version 2, October 25, 2013
Added a note about more possible reasons for returning EGL_BAD_FORMAT.
+Version 3, February 5, 2014
+Support for passing mult
This adds a separate nested client to the weston-nested example which
will create YUV buffers using libva. The code is based on the
putsurface test in libva. The client can be used by passing the -y
option to weston-nested.
---
.gitignore |1 +
Makefile.am |
This bumps the DRI image extension to version 9 and adds an attribute which
can be used with queryImage to get the image's offset within the buffer. This
will be used with eglCreateWaylandBufferFromImageWL in order to create a
buffer using an image which represents a plane of a planar buffer.
---
these problems can be but are not limited to
unsupported tiling modes, inaccessible memory or an unsupported pixel
format.
@@ -99,3 +133,6 @@ Revision History
Initial draft (Neil Roberts)
Version 2, October 25, 2013
Added a note about more possible reason
In order to support YUV formats in CreateWaylandBufferFromImageWL we need to
be able to check whether the compositor supports a larger number of formats so
storing them in flags is a bit awkard. Instead all of the formats are now
stored in a sorted array using wl_array. A binary search is used to c
Hi,
I had a look at trying to get the
EGL_WL_create_wayland_buffer_from_image extension to support YUV
buffers. The main difficulty is that we don't get a single EGLimage
when using a planar buffer with the EGL_WL_bind_wayland_display
extension and instead we get a separate image for each plane. I
The previous implementation of the wl_container_of macro was
dereferencing the sample pointer in order to get an address of the
member to calculate the offset. Ideally this shouldn't cause any
problems because the dereference doesn't actually cause the address to
be read from so it shouldn't matter
Jonathan Howard writes:
> wl_list_remove changed isn't 100% guaranteed to not break anything, on
> the other hand there is no guarantee the code does not have the fatal
> double remove already.
We definitely do already have a double-remove bug in Weston as described
here:
http://lists.freedeskt
It looks like this bit of code is trying to disable the prime capability if
the driver doesn't support createImageFromFds. However the logic looks a bit
broken and what it would actually do is disable all other capabilities apart
from prime. This patch fixes it to actually disable prime.
---
src/e
It looks like the rest of the code assumes that shsurf->children_link
is always a consistent list. For example, shell_surface_set_parent
resets children_link to the empty list after it unlinks a child from
its parent. The destroy_shell_surface code just calls wl_list_remove
which leaves the list no
This problem was found while looking at the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72612
It turns out the patch doesn't help to fix the bug but I think it
would be a good thing to do anyway.
--- >8 --- (use git am --scissors to automatically chop here)
The s
Hi,
Here is a rebased version of the patch. The old one didn't apply
cleanly anymore because of some changes in tests/Makefile.am
I think there is some confusion about why it ends up using 3 buffers
and I also keep getting in a muddle about it. I'll try to describe
what I think is happening here.
use a dispatch.
That patch also moves the call to dri2_dpy->flush->flush further up. I'm
not sure if that is necessary. It also adds a pointer to the wl_display
in struct dri2_egl_surface which definitely looks unnecessary. So I
think Axel's patch makes more sense.
Reviewed-by: N
Kristian Høgsberg writes:
> That's a nice idea. Could we just generate it from configure.ac by
> listing it in AC_CONFIG_FILES?
Sadly that doesn't work because the autoconf expansions still include
variables for make. Eg, @bindir@ expands to ${exec_prefix}/bin. I think
that is needed so that yo
Previously weston.ini had hardcoded paths for the weston-* clients in
/usr/bin and /usr/libexec. This was a bit annoying when testing Weston
because you wouldn't usually install those in the system prefix. This
patch adds a make rule to automatically generate weston.ini from a
template file with so
Looking at the Weston branch again I found some problems so I've force
pushed a new version.
I wasn't destroying the wl_buffer that the subcompositor creates with
eglCreateWaylandBufferFromImageWL when the client destroys its buffer.
This doesn't really matter because in this example the client do
Hi,
I think this thread has gotten a bit tangled so I've done a bit of minor
rebasing for the patches and pushed them all to github:
https://github.com/bpeel/wayland/commits/wip/wayland-subcompositor
https://github.com/bpeel/mesa/commits/wip/wayland-subcompositor
https://github.com/bpeel/weston/c
Bill Spitzak writes:
> Can you explain why "consistency" is so important for the window
> frame, but is not a problem for the buttons and scrollbars and text
> fields and everything else inside the frame?
In the case of a game there probably wouldn't be any buttons or
scrollbars so the only thin
Thiago Macieira writes:
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.
I think it's a shame to throw out the idea of making the policy be that
clients are allowed to expect SSD if they don't want to draw decorations
themselve
The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.
The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers
As per Kristian's suggestion we can avoid the problem of effectively
disabling the event queuing mechanism by only doing the sync request
when the swap interval is zero. To fix the bug of using three buffers
we can just block for the frame callback in get_back_bo instead of
swap_buffers. I was orig
It's not obvious that these functions are needed so it would be good
to have some documentation for them.
---
doc/doxygen/Makefile.am | 3 ++-
src/wayland-shm.c | 64 +
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/doc/doxygen
Thanks for the feedback. Here is a version two of the patch which
fixes some merge conflicts on master and adds support for the pixman
renderer.
Kristian wrote:
> As for the pixman renderer it should be a matter of just wrapping
> the calls to pixman_image_composite32() in
> pixman_renderer_read_
Ok, here is a second version of the patch which leaves the signal
handler permanently installed and uses thread-local storage to keep
track of the current pool.
Regards,
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
Linux will let you mmap a region of a fil
Tomeu Vizoso writes:
> What I fail to see is why a single sync should be enough, as we don't
> know when the GPU will signal that it's done with the buffer that we
> are waiting to be released.
You are right that we don't know when the GPU will release the buffer.
However we are not waiting for
Here is a test case which demonstrates the 3 buffers problem. It is
fixed by the eglSwapInterval patch because that installs a sync event,
but note the problem isn't really related to eglSwapInterval and is
something we should probably fix anyway.
Regards,
- Neil
--- >8 --- (use g
Jason Ekstrand writes:
> You don't have to continuously sync, just sync after every
> attach/commit. While it may be somewhat non-obvious, I don't see how
> calling sync once per frame is any worse than setting some flag
> somewhere.
Hrmm thinking about it, I suppose sending the sync request isn
wayland_buffer_from_image
+
+Contributors
+
+Neil Roberts
+ Axel Davy
+Daniel Stone
+
+Contact
+
+Neil Roberts
+
+Status
+
+Proposal
+
+Version
+
+Version 2, October 25, 2013
+
+Number
+
+EGL Extension #not assigned
+
+Dependencies
+
+Requires EGL 1.4 or later. This
Just to be clear, I think the discussion about whether to queue release
events is no longer related to implementing eglSwapInterval(0) so it
shouldn't hold up the patch. As far as I understand if you want to
render at the maximum rate you need four buffer slots and being able to
disable the queuing
Ok, here is version 4 of the patch taking into account the discussion
with Jason Ekstrand. The assumption is that if we have enough buffer
slots then we should always get a release event immediately after one
of the attaches. That means we can just rely on sending a sync request
after the commit in
Hi
Thanks for the interesting insights.
> It seems to me as if the default should always be to just send the
> event.
I think I would vote for leaving the default as it is, ie, queuing the
release events. It's really quite a corner case that delaying events has
any effect on an application becau
The test attaches a buffer and then verifies that it doesn't get the
release event until a roundtrip is issued causing the event queue to
flush. It then sets the release mode to immediate and then verifies
that it doesn't need to do a roundtrip to get the release event. The
default mode is then use
Neil Roberts writes:
> Currently the only proposed complete solution is just to add a request
> to explicitly disable the queuing mechanism.
I started writing this patch but I've hit a stumbling block while trying
to make use of it in Mesa. Adding the new request requires altering
Implements the wl_surface.set_release request which just causes the
buffer release events to be sent with wl_resource_post_event instead
of wl_resource_queue_event. The release mode is part of the
double-buffered surface state and gets reset to the default as soon as
a commit is performed on the su
Adds a request called wl_surface.set_release which provides a way for
a client to explicitly disable the queuing mechanism for buffer
release events so that it can get them as soon as the buffer is no
longer being used. This is useful for example when doing
eglSwapInterval(0) because in that case t
Here is a quick summary of the discussion about the release event
handling that has partially happened on this list and partially on IRC.
Currently the release events are put into a queue so that they are only
sent alongside another event sent by the compositor in order to avoid
waking up the clie
Neil Roberts writes:
> I think that would mean you could cause tearing if you are using
> eglSwapInterval(0) because you could write into the released buffer
> while the GPU is actually still rendering the previous frame using the
> buffer in a texture.
>
> I think this doesn
Previously if you add a second finger while moving a window with a
touch grab then the position will keep jumping between the position of
each finger as you move them around. This patch changes it so that it
keeps track of the first touch id that starts the grab and only
updates the grab position w
Previously if you move a window around and temporarily add a second
finger then it will cancel the grab even though the original finger is
still held on the screen. It seems more robust to avoid cancelling the
grab until all fingers have been removed.
---
src/shell.c | 4 +++-
1 file changed, 3 in
When holding the compositor super key the touch events can now be used
to move a window.
---
src/shell.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/shell.c b/src/shell.c
index 4a0c122..2822a2b 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2774,6 +2774,26 @@ mov
Adds a new binding type for touch events via the new function
weston_compositor_add_touch_binding. The binding can only be added for
a touch down with the first finger. The shell now uses this to install
a binding to activate the current surface.
---
src/bindings.c | 36 +
I don't think this function would help in cases where the buffer is
released after the frame is drawn but the compositor is not drawing
anything else. Ie, if the events were like this:
1 - client attaches a buffer and waits for the next release
2 - compositor redraws a frame
3 - the redraw complet
Hi
José Bollo writes:
> That is a really interesting point.
> I have two questions about it:
> - Is it normal that the client trucates the buffer? Is your patch
>designed to allow normal operations? or to allow forbiden uses?
> - If it is not "normal", is there good reasons to continue to
This wraps all accesses to an SHM buffer between wl_shm_buffer_begin
and end so that wayland-shm can install a handler for SIGBUS and catch
attempts to pass the compositor a buffer that is too small.
Note, this patch doesn't do anything to fix the pixman renderer.
---
src/compositor-drm.c | 3 ++
Linux will let you mmap a region of a file that is larger than the
size of the file. If you then try to read from that region the process
will get a SIGBUS signal. Currently the clients can use this to crash
a compositor because it can create a pool and lie about the size of
the file which will cau
Pekka Paalanen writes:
> If not, is there not a possibility to break existing applications by
> blocking too early?
Yes, you're right, the patch is nonsense because it won't work when the
application does wl_display_dispatch_pending because it might end up
with some events still in the queue but
One idea to fix this might be to make dispatch_queue only ever
dispatch the events that were current when the loop is started. That
way if any further events are added while processing the current
events it will give control back to the main loop before processing
them.
Here's a not-heavily-tested
1 - 100 of 155 matches
Mail list logo